From: thomas at tada.se (Thomas Hallgren)
Date: Mon, 25 Sep 2006 17:58:31 +0200
Subject: [Pljava-dev] UDT send and receive
In-Reply-To: <4517F039.6050709@logix-tt.com>
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>
Message-ID: <4517FCA7.8050208@tada.se>

Markus Schaber wrote:
> Hi, Thomas,
>
> Markus Schaber wrote:
>
>   
>> I'm definitely planning to look into the C code. However, I might need
>> some time to understand the "inner workings", and there's some higher
>> priority work on my table, so it might take a few days.
>>     
>
> I'm currently stuck in the C code in UDT.h.
>
> 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.

>  Also, there are CREATE FUNCTION calls in the example on
> http://wiki.tada.se/wiki/display/pljava/Creating+a+Scalar+UDT+in+Java
> but the java code does not actually define them.
>
> Is that assumption correct?
>
>   
Yes. They will all be redirected to the UDT_input, UDT_output, UDT_send, 
and UDT_receive that you'll find in UTD.c

> 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?

> 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?


> Btw, I have the impression that I'm the first one actually trying VARLEN
> UDT mapping with pljava :-)
>
>   
You are. As you've discovered, it's broken.

Regards,
Thomas Hallgren