[Pljava-dev] UDT send and receive

From: thomas at tada(dot)se (Thomas Hallgren)
To:
Subject: [Pljava-dev] UDT send and receive
Date: 2006-09-25 15:58:31
Message-ID: 4517FCA7.8050208@tada.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

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

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Scott Petersen 2006-09-25 16:14:00 [Pljava-dev] Error trapping help
Previous Message Thomas Hallgren 2006-09-25 15:42:11 [Pljava-dev] Error trapping help