From: schabi at logix-tt.com (Markus Schaber)
Date: Fri, 29 Sep 2006 12:14:41 +0200
Subject: [Pljava-dev] VarLenTuple example code
In-Reply-To: <451BF32A.7000405@tada.se>
References: <451BD0B1.8000408@logix-tt.com>	<451BD2F4.60202@tada.se>
	<451BD650.2080201@logix-tt.com>	<451BDB5E.1020107@tada.se>
	<451BE12B.6060809@logix-tt.com> <451BF32A.7000405@tada.se>
Message-ID: <451CF211.7000000@logix-tt.com>

Hi, Thomas,

Let's recall the 4 representations I enumerated:

A) the "canonical text representation"
B) the "canonical binary representation"
C) the "internal" representation
D) Java Objects.

Thomas Hallgren wrote:

> No. Just one SQLData implementation per type. The parameter to
> readSQL should be an SQLInput wrapping the exact bytes that you would
> expect to be the parameter to the receive function. The writeSQL will
> create the bytes that would otherwise be be created by the send
> function.

Ok, so then the writeSQL and readSQL are meant to convert between the
representations B and D.

From the examples and some points of our discussion, I had the
impression they should convert between C and D.

> Normally when you create a type in PostgreSQL you'd create four
> functions in C. Now you create four methods in Java instead:
> 
> input -> parse 
> output -> toString
> receive -> readSQL
> send -> writeSQL

Yes. Those four functions, as I understand it, do the following
representation conversions:

input:    A -> C
output:   C -> A
receive:  B -> C
send:     C -> B

The java methods should do the following tasks:

parse:    A -> D
toString: D -> A
readSQL:  B -> A & C -> A
writeSQL: A -> B & A -> D

The whole thing only makes sense for me under the assumption that the
representations B and C are identical.

But having them different is the whole point of why explicit send/
receive functions were invented in PostgreSQL, IIRC.

They are not equal for all PostgreSQL numerical datatypes I checked in
source, those convert to network byte order in send(), and back to
platform in receive().

The same is for PostGIS, which uses a compatible extension of the
OpenGIS defined "Well Known Binary" standard format for B, and an
optimized format in platform endiannes that tends to change between
major releases for C.


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