Skip site navigation (1) Skip section navigation (2)

Re: Status of binary protocol usage?

From: Mikko Tiihonen <mikko(dot)tiihonen(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, aaime74 <andrea(dot)aime(at)gmail(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Status of binary protocol usage?
Date: 2007-07-19 12:27:08
Message-ID: 1184848028.1632.25.camel@dual.local (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
tom lane wrote:
> aaime74 <andrea ( dot ) aime ( at ) gmail ( dot ) com> writes:
> > Hum, interesting. What would be the boatload of disadvantages?
> Portability and cross-machine compatibility, or lack of same.

I can understand that future postgres versions can change the binary
protocol, but I hope it is done so that it can be deduced from the
version or alternatively similarly to the float/long timestamp
so that the server informs about its usage of new features.

But I cannot understand why the protocol would be allowed to ever
vary with the server 32/64bitness or endiandness. And at least to my
current understanding it doesn't. And if those are taken care of
in the server side then there shouldn't be any problems because the
java side by definition already is cross-machine compatible and portable.

But if you really think that the binary protocol varies so much with the
server then why is it documented (even as much as it is) and why is the
documentation warning about the possible compatibility problems.

> It's tough enough trying to make things work for relatively primitive
> datatypes like float.  I can hardly imagine that anyone would want to
> support binary representations across platforms for geometric types.

I think that is why the postgres binary protocol allows requesting use
of binary types for each input and output parameter separately.
In addition the jdbc driver (with my proposed patches) allows
controlling binary/text format of each type separately to work around any
future changes in the protocol.

In the proposed binary protocol changes one just needs to add a few
lines code to send or receive path (which ever is the bottleneck) whenever
a new datatype that is performance critical for an application is found.

Anyway, I seem to have vanished for half a year but I could try to pick up
things from where I left them. Kris had some good ideas on how to hack
the test framework in order to ensure that the binary patches would not
cause any regressions.


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2007-07-19 12:34:00
Subject: Re: Using bytea with ResultSet.getBytes("..."). Problem. Help!!
Previous:From: Dave CramerDate: 2007-07-19 10:44:26
Subject: Re: Using bytea with ResultSet.getBytes("..."). Problem. Help!!

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group