agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feedSubject: [Pljava-dev] UDT send and receive
Date: Mon, 25 Sep 2006 17:58:31 +0200
Message-ID: <4517FCA7.8050208@tada.se> (raw)
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>
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
view thread (6+ messages) latest in thread
Message-ID: <4517FCA7.8050208@tada.se>
Permalink: ../4517FCA7.8050208@tada.se/
Also on: postgresql.org/message-id/4517FCA7.8050208@tada.se
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pljava-dev@postgresql.org
Subject: Re: [Pljava-dev] UDT send and receive
In-Reply-To: <4517FCA7.8050208@tada.se>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox