From: thomas at tada.se (Thomas Hallgren)
Date: Mon, 25 Sep 2006 22:47:09 +0200
Subject: [Pljava-dev] UDT send and receive
In-Reply-To: <45183343.8000105@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>
	<4517FCA7.8050208@tada.se>	<451815CF.9010507@logix-tt.com>
	<451826E8.1000404@tada.se> <45183343.8000105@logix-tt.com>
Message-ID: <4518404D.2050407@tada.se>

Markus Schaber wrote:
 > I erroneously assumed the same Magic like the input/output functions
 > mapping to parse()/toString().
 >
Nope, no magic :-)

 > You suggest to implement send and receive as normal static functions in
 > Java, and then use CREATE FUNCTION without the "UDT[foo] output" special
 > syntax.
 >
Unless you already have a type with send/receive written in C, then yes. 
If you want to map a pre-existing type, you can still do that, but then 
you need to duplicate the send/receive functionality in Java in order to 
access the internals of that type.

 > The Problem I see here is that, for the receive function, the Datatype
 > "internal" is used as function parameter, which currently has no mapping
 > for pljava, at least according to
 > http://wiki.tada.se/wiki/display/pljava/Default+Type+Mapping
 >
In some sense, that's true. The mapping is in itself internal. It's 
there though...

 > So I can define the send function (which returns bytea) the way you
 > suggest, but not the receive function.
 >
Yes you can. The internal receive function will map the internal bytea 
that it receives to an SQLInput (the SQLInputFromChunk) and will pass it 
to a SQLData implementation (which the user must provide).

 > We have (at least) 4 different representations:
 >
 > A) the "canonical text representation"
 > B) the "canonical binary representation"
 > C) the "internal" representation
 > D) Java Objects.
 >
 >
 > C) is what PostgreSQL passes around (to PostGIS C functions as well as
 > to the PLJava glue code), and stores on disk. The size is defined as
 > "internallength" in the datatype, and contained in a 4-byte VARLEN
 > header for variable length datatypes which have internallength set to
 > -1. (let's ignore TOAST and 0-terminated Strings for simplification.)
 >
 > D) is what's passed around in "user functions" in pljava lands, 
obviously.
 >
 > A) is used in psql, pg_dump, non-binary COPY, the V2 protocol and the
 > text mode of the V3 protocol.
 >
 > B) is used in binary COPY and the binary mode of the V3 protocol.
 >
 >
 > The pljava UDT mapping converts between C and D via the readSQL() and
 > writeSQL() methods.
 >
 > PostgreSQL uses the input and output functions defined for the type to
 > convert between A and C.
 >
 > The send and receive functions for the datatype convert between B and C.
 >
 > http://www.postgresql.org/docs/8.1/interactive/xtypes.html contains an
 > example with some less-sophisticated, but explicitly coded send and
 > receive functions.
 >
 > I hope it is understandable what I try to explain.
 >
Yes, this makes sense to me. Do you still find this approach limiting or 
is it in line with what you would like to have?

Regards,
Thomas Hallgren