agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

Subject: [Pljava-dev] readBytes() / writeBytes()
Date: Fri, 22 Sep 2006 17:25:18 +0200
Message-ID: <4514005E.2010703@tada.se> (raw)
In-Reply-To: <4513FD21.5080608@logix-tt.com>
References: <4512F5E4.9060600@logix-tt.com>
	<45139C17.3050006@tada.se>
	<4513A107.4060809@logix-tt.com>
	<4513A3ED.3050401@tada.se>
	<4513E2C0.3050804@logix-tt.com>
	<4513E52B.5080108@tada.se>
	<4513F1A0.8020800@logix-tt.com>
	<4513F639.3000108@tada.se>
	<4513FD21.5080608@logix-tt.com>

Markus Schaber wrote:
> Hi, Thomas,
>
> Thomas Hallgren wrote:
>
>   
>> Markus Schaber wrote:
>>     
>>> What's the best way to fix it? Using native functions for reading the
>>> values?
>>>       
>> It's two fixes basically. The endian stuff can be fixed in Java and
>> directly in the SQLOutputToChunk and SQLInputFromChunk classes. The
>> methods should mimic what java.nio.DirectByteBuffer does.
>> java.nio.ByteOrder.nativeOrder() gives the native ordering.
>>     
>
> Ah, great. I'll look into it.
>
>   
>> The four byte offset stuff must be fixed in the C file that corresponds
>> to the SQLInputFromChunk. There's no need to fix for the output since
>> such a fix will introduce an ambiguity. The length is determined by the
>> number of bytes written anyway, so why introduce a need to go back and
>> add it. Important to document this behavior though.
>>     
>
> Its assymetric when we read the length on input, but don't write it on
> output, I would hesitate to use this assymetry.
>
> Maybe the code should check whether the length header is equal to the
> real length, and raise a warning otherwise?
>
>   
The problem is that you often don't know the length when you start 
writing. And there's no way to do a seek and go back and rewrite once 
you're done. But as you mention, asymmetry is not good and far from 
everyone will consult the documentation.

A good compromise is perhaps to to introduce the check that you suggest 
but also allow the length to be zero? That way you will always need to 
write the length and if it's not known at that time, you just write zero 
and PL/Java will assign it once you're done writing.

> Additionally, the underlying code could intercept an writeInt() at
> offset 0, and allocate the underyling StringInfo to the right size. This
> avoids repeated reallocation on larger values. (Geometries representing
> country borders can easily get several MB large.) But, on the other
> hand, this would slow down all writeInt() calls, so I don't know whether
> it's worth the effort.
>
>   
In most cases (for small datatypes) you'll only loose with that 
approach. If it's very common that you write long sequences of data, it 
will be a win (reallocation is not cheap). I'd leave it for now and 
perhaps make it configurable sometime in the future.

Regards,
Thomas Hallgren

view thread (13+ messages)  latest in thread

Message-ID: <4514005E.2010703@tada.se>
Permalink:  ../4514005E.2010703@tada.se/
Also on:    postgresql.org/message-id/4514005E.2010703@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: <4514005E.2010703@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