[Pljava-dev] VarLenTuple example code

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