From: thomas at tada.se (Thomas Hallgren)
Date: Fri, 22 Sep 2006 10:50:53 +0200
Subject: [Pljava-dev] readBytes() / writeBytes()
In-Reply-To: <4513A107.4060809@logix-tt.com>
References: <4512F5E4.9060600@logix-tt.com> <45139C17.3050006@tada.se>
	<4513A107.4060809@logix-tt.com>
Message-ID: <4513A3ED.3050401@tada.se>

Markus Schaber wrote:
> Hi, Thomas,
>
> Thomas Hallgren wrote:
>
>   
>>> I just stumbled about the readBytes() / writeBytes() methods from 
>>> SQLInputFromChunk / SQLOutputFromChunk classes.
>>>
>>> They seem to assume that every array has a 2-byte length header.
>>>
>>>       
>> Those classes are part of the JNI interface. They map to the internal
>> PostgreSQL StringInfo structure. They are *not* intended for any other use.
>>     
>
> Ok, it seems I've been mislead by reading the docs and source, sorry.
> Please tell me, what's their use, if not implementing datatype mappings?
>
>   
Their use *is* to implement datatype mappings. PostgreSQL's receive/send 
functions use the StringInfo to pass datastructures.

> As far as I can see, they're the only implementations of the
> SQLInput/ SQLOutput interfaces one uses to implement a custom data type.
>
>   
You use SQLInput/SQLOutput to map all datatypes but the pre-mapped ones 
(i.e. int, long, float, etc.) with PL/Java.


> So, when mapping a datatype (like the ComplexTuple example delivered
> with pljava), one is actually using those classes.
>
>   
Correct. But there's more to it. Please read: 
http://wiki.tada.se/wiki/display/pljava/Mapping+an+SQL+type+to+a+Java+class. 
There's an example mapping the PostgreSQL geometric point type to a Java 
class.


> And as the storage format of the PostGIS datatypes is determined by the
> C implementation in liblwgeom.so, I have to adhere to that format.
>
>   
Yes you do. But that should not be a problem.

> I have to understand how SQLInputFromChunk and SQLOutputFromChunk
> work, to find the most efficient implementation while still being
> compatible to that predefined binary format.
>
> As it looks now, my only possibility seems to find out the native
> endianness of the machine, and then read the data byte-for-byte via
> readByte(), and then put it together for myself. Most of the code should
> be copyable from the WKB parsers I've already written, so no real
> effort, but I'm still afraid that calling a native function per byte
> will not perform best.
>
>   
You should not bother with endianess. The implementation deals with that.

Kind Regards,
Thomas Hallgren