Re: Binary tx format for an array?

Michael

I'm curious. Are you attempting to implement the binary protocol for
the jdbc driver ?

If so, how are you dealing with date types which are either 64 bit or
floating point.

Have you done any testing to see if it is actually faster ?

There's certainly no question with timestamp/date parsing, others may
be questionable .

Dave
On 23-Jun-06, at 4:22 AM, Michael Guyver wrote:

> On 22/06/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> No, in the buffer they'll be in network (big-endian) byte order,
>>
>> [0x00][0x00][0x00][0x17]
>
> On 22/06/06, Mark Lewis <mark(dot)lewis(at)mir3(dot)com> wrote:
>> Java tried so hard to hide endianness from you that it didn't provide
>> any real support for those times when you DO need to be aware of
>> it. So
>> the "convention" looks kind of like this (snipped from the PG JDBC
>> driver):
>>
>> public void SendInteger4(int val) throws IOException {
>> SendChar((val >> 24)&255);
>> SendChar((val >> 16)&255);
>> SendChar((val >> 8)&255);
>> SendChar(val&255);
>> }
>
> Of course that's right: I got myself confused.
>
> Thanks very much for your help, no doubt I'll be back for some more
> (please sir) in the future.
>
> I'm optimistic I'm on the right track but wanted to conceive a way of
> unit testing the different Java classes that represent PG types, and
> their binary Tx and Rx methods.
>
> One way I thought of doing this is simply to send the values over JDBC
> (specifying binary parameters) and check the contents of a test table
> once all the inserts are done, but such unit tests get very messy very
> quickly, and you wind up storing your expected results in a different
> file, which is firstly something you have to keep in sync with the
> source code and secondly tends to grow and become unmanageable very
> quickly.
>
> Another way would be to use the JNI mechanism to talk directly to the
> PG code, calling the xxxrecv() functions for the type you're testing,
> reading back the type's value using the xxxsend() method. Not being a
> C man, I'm not sure how easy this would be and would appreciate any
> suggestions.
>
> Regards,
>
> Michael
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>