[Pljava-dev] UDT send and receive

Hi, Thomas,

Thomas Hallgren wrote:

>> From looking at the code, it seems to assume that the send and receive
>> code assumes that the internal (on-disk) representation is the same than
>> the one used for binary I/O, rather than relying on the send and receive
>> functions.
> Not sure what you mean. The UDT functions *are* the send/receive
> functions (with an added UDT parameter). They don't care much about the
> representation as such. There's a length (-2, -1 or a verbatim length)
> and then there are bytes of data. The send fucntion uses byteasend,
> unknownsend, or a StringInfo depending on the length. The receive
> performs the corresponding read. Totally representation agnostic.

Yes. And, as I said, they send the on-disk data 1:1.

PostGIS internally uses a different storage format compare to binary
input/output, for abstraction purposes, and the send and receive
functions perform some conversions (including adding varlena header, and
adopting byte order).

In my eyes, your current approach will fail when someone gets a binary
dump of the data via COPY, and then reloads the data on a platform with
different endianness. And clients using binary V3 protocol need to know
the server's endianness.

>> At least PostGIS currently uses a slightly different internal
>> representation internally compared to what send/receive use. The
>> internal on-disk format is optimized, the external representation is an
>> upwards compatible extension to the OpenGIS standardized WKB format.
>>
> OK, so if you want to read that in Java, I assume your SQLData
> input/outpout methods must deal with that. Perhaps I miss the point
> altogether here. Who converts between the internal format and the
> on-disk format?

For PostGIS: the send and receive functions which are given at CREATE
DATATYPE.

http://svn.refractions.net/postgis/trunk/lwgeom/lwgeom_inout.c has the C
code for those functions, LWGEOM_recv() and LWGEOM_send() which call the
conversion routines WKBFromLWGEOM and LWGEOMFromWKB under the hood.

>> So, from my understanding of the code, it's currently impossible to
>> implement an 1:1 replacement for PostGIS in pljava. (Not that I
>> seriously plan to do this.)
>
> Not sure I understand why. Why can the data conversion not take place in
> Java, should you choose to do that?

Because there is nobody that calls the appropriate Java functions.

When an SQL COPY reads binary data, it is passed through the RECEIVE
function in UDT.c, and then put on the platters.

I hope that I managed to explain the problem, if not, please ask.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20060925/33eaa75f/attachment.bin>