From: schabi at logix-tt.com (Markus Schaber) Date: Mon, 25 Sep 2006 19:45:51 +0200 Subject: [Pljava-dev] UDT send and receive In-Reply-To: <4517FCA7.8050208@tada.se> References: <4512F5E4.9060600@logix-tt.com> <45139C17.3050006@tada.se> <4513A107.4060809@logix-tt.com> <4513A3ED.3050401@tada.se> <4513E2C0.3050804@logix-tt.com> <4513E52B.5080108@tada.se> <4513F1A0.8020800@logix-tt.com> <4513F639.3000108@tada.se> <45140A51.8030605@logix-tt.com> <45144DEB.2050107@tada.se> <45150E10.8030907@logix-tt.com> <4517F039.6050709@logix-tt.com> <4517FCA7.8050208@tada.se> Message-ID: <451815CF.9010507@logix-tt.com> 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: