agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

Subject: [Pljava-dev] readBytes() / writeBytes()
Date: Fri, 22 Sep 2006 17:11:29 +0200
Message-ID: <4513FD21.5080608@logix-tt.com> (raw)
In-Reply-To: <4513F639.3000108@tada.se>
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>

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?

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.


> I'm not too concerned with backward compatibility on this. The current
> behavior is severely broken. It must be fixed.

Ok, I fully agree.


Thanks,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20060922/d4f608de/attachment.bin;

view thread (13+ messages)  latest in thread

Message-ID: <4513FD21.5080608@logix-tt.com>
Permalink:  ../4513FD21.5080608@logix-tt.com/
Also on:    postgresql.org/message-id/4513FD21.5080608@logix-tt.com

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: <4513FD21.5080608@logix-tt.com>

* 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