From: thomas at tada.se (Thomas Hallgren)
Date: Fri, 29 Sep 2006 12:51:25 +0200
Subject: [Pljava-dev] VarLenTuple example code
In-Reply-To: <451CF211.7000000@logix-tt.com>
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> <451CF211.7000000@logix-tt.com>
Message-ID: <451CFAAD.9030603@tada.se>

Markus Schaber wrote:
 > 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.
 >
 >
 > Ok, so then the writeSQL and readSQL are meant to convert between the
 > representations B and D.
 >
 >
 > 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

So far, I agree.

 > readSQL:  B -> A & C -> A
 > writeSQL: A -> B & A -> D
 >
Where did A come into the picture? readSQL/writeSQL has nothing 
whatsoever to do with text representation. They perform the work of 
send/receive and work with binary representations only. Only difference 
is that they bypass the C and instead go directly to D.

readSQL: B -> D
writeSQL: D -> B


 > 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.
 >
Yes, I agree with that. B and C are different.

For the sake of the argument, lets assume that we create a Java type 
that corresponds to the internal format C. That Java type is essentially 
a byte[] but we wrap it in a SQLData implementation in order to use it 
as a type. For this type, we can claim that C == D since its 
representation *is* the internal representation.

The readSQL of this type will then perform *exactly* the same work as 
the receive function do, i.e. B -> C. Its corresponding writeSQL method 
will perform *exactly* the same work as send, i.e. C -> B.

In Java, the above object is cannot be used for much. It's just an 
opaque sequence of bytes. So instead of just wrapping the byte[], you 
probably add some more semantics to it. When you do that, you also 
rewrite the readSQL go directly from B -> D.

In essence, C is the internal representation used in C-functions 
(structures etc.) whereas D is the internal representation used by Java 
methods (real objects). They both stem from B in case of send/receive or 
from A in case of input/output.

Regards,
Thomas Hallgren