From: schabi at logix-tt.com (Markus Schaber)
Date: Fri, 29 Sep 2006 14:01:15 +0200
Subject: [Pljava-dev] VarLenTuple example code
In-Reply-To: <451CFAAD.9030603@tada.se>
References: <451BD0B1.8000408@logix-tt.com>	<451BD2F4.60202@tada.se>
	<451BD650.2080201@logix-tt.com>	<451BDB5E.1020107@tada.se>
	<451BE12B.6060809@logix-tt.com>
	<451BF32A.7000405@tada.se> <451CF211.7000000@logix-tt.com>
	<451CFAAD.9030603@tada.se>
Message-ID: <451D0B0B.4010008@logix-tt.com>

Hi, Thomas,

Thomas Hallgren wrote:

>> readSQL:  B -> A & C -> A
>> writeSQL: A -> B & A -> D

Sorry, I messed that one up. Should read:

readSQL:  B->D & C->D
writeSQL: D->B & D->C

> Where did A come into the picture? readSQL/writeSQL has nothing
> whatsoever to do with text representation. They perform the work of
> send/receive and work with binary representations only. Only difference
> is that they bypass the C and instead go directly to D.

But C is the one that's stored on disk by PostgreSQL, neither D nor B.

>> The whole thing only makes sense for me under the assumption that the
>> representations B and C are identical.
>>
>> But having them different is the whole point of why explicit send/
>> receive functions were invented in PostgreSQL, IIRC.
>>
> Yes, I agree with that. B and C are different.
> 
> For the sake of the argument, lets assume that we create a Java type
> that corresponds to the internal format C. That Java type is essentially
> a byte[] but we wrap it in a SQLData implementation in order to use it
> as a type. For this type, we can claim that C == D since its
> representation *is* the internal representation.

But C!=D, as PostgreSQL does not know how to serialize Java Objects, AFAIK.

And when you call writeSQL() on the java object, you set B==C and
effectively store B on disk.

This may ok for new datatypes developed purely in java, although
possibly be suboptimal. And for them, it makes sense to have the
SQLInput/SQLOutput always using network byteorder, as they were before I
had my patch.

But it does not work for someone creating a drop-in replacement for an
existing datatype that was implemented in C previously, as he has to
keep both B and C as they've been before, to be compatible.

> In essence, C is the internal representation used in C-functions
> (structures etc.) whereas D is the internal representation used by Java
> methods (real objects). They both stem from B in case of send/receive or
> from A in case of input/output.

But C is the representation that's stored on-disk, and passed around
internally on the PostgreS' side, into functions implemented in other
procedural languages like C or plpython/plperl. So we cannot simply
ignore it, IMHO.

For my plans regarding PostGIS, I currently only want a type mapping, so
I need conversions between C and D. That works fine, AFAICS, at least
with the endianness patch applied.

But should we ever want to replace the C implementation with a java
implementation for some reason, and stay drop-in compatible wr/t both
clients seeing B, and 3rd-party extensions (like a plpython mapping)
seeing C, that would be impossible using the current pljava design, correct?

Note: I don't want any changes or fixes for that, I only want to be sure
that I understood the internals correctly, and have it documented
properly (I'm willing to write and submit that piece of documentation).

Thanks,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org