agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

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

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

view thread (13+ messages)  latest in thread

Message-ID: <4513A3ED.3050401@tada.se>
Permalink:  ../4513A3ED.3050401@tada.se/
Also on:    postgresql.org/message-id/4513A3ED.3050401@tada.se

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pljava-dev@postgresql.org
  Subject: Re: [Pljava-dev] readBytes() / writeBytes()
  In-Reply-To: <4513A3ED.3050401@tada.se>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox