[Pljava-dev] VarLenTuple example code

Markus Schaber wrote:
> Hi, Thomas,
>
> Thomas Hallgren wrote:
>
>> No, in that case you must have misunderstood. When you do that, you
>> remove the middleman that sets up the correct SQLData semantics. The
>> send/receive functions in PostgreSQL maps to the readSQL/writeSQL
>> methods in SQLData. The readSQL is the method that supposedly populate
>> your VarLenTuple from the byte buffer native presentation (wrapped in
>> the SQLInput). The writeSQL creates the native presentation byte buffer
>> (wrapped in the SQLOutput) from the VarLenTuple. There's absolutely no
>> need for you to create some other send/receive mechanism in Java.
>
> I just re-read your last mail, and I now see that I misread it.
>
> But I still don't grasp how the SQLData implementation (readSQL/
> writeSQL) knows whether it's supposed to read or write the internal
> on-disk representation (type C) or the external binary (type B) format?
>
> Do I need three different SQLData implementations, one for send (read C,
> write B), one for receiving (read B, write C), and one for the type
> mapping (read C, write C)?
>
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.

> And which of them are supposed to have the toString()/parse() methods?
>
The parse()/toString() methods are a direct replacements of the mandatory PostgreSQL
input/output functions.

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

> Anyhow, I'm going to re-read our discussion and the source tomorrow,
> maybe a little more sleep helps. :-)
>
:-)

Regards,
Thomas Hallgren