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

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