[Pljava-dev] readBytes() / writeBytes()

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