Re: Binary params in libpq - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Binary params in libpq
Date
Msg-id AANLkTi=7=xDZVR1SrqszfW4J5FZSZ9vQRsKqp7-TFLCK@mail.gmail.com
Whole thread Raw
In response to Re: Binary params in libpq  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Binary params in libpq
Re: Binary params in libpq
Re: Binary params in libpq
List pgsql-general
On Sun, Feb 27, 2011 at 7:39 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 28/02/2011 7:48 AM, Merlin Moncure wrote:
>
>>> How stable is the binary representation for the PostgreSQL types? We
>>> may just pass bytea data in binary format and pass everything else as
>>> text parameters, or pass different types too as binary, if performace
>>> would benefit. Did binary format ever changed in the past (at least
>>> since the introduction of the V3 protocol)?
>
> AFAIK, the `timestamp' type moved from a floating-point to an integer
> representation internally, which would've affected the binary protocol
> representation. That was even a compile-time config option, so it could be
> different between two different Pg installs with the same version.

Actually, this has always been a compile time option on the server as
far as i remember and there is protocol support for it -- libpq tells
you how it has been set...you've always had to deal with this
(libpqtypes, which I've mentioned several times as the correct way to
'do' binary with libpq, handles this for you).  Only the default
setting was changed.  Timestamps are the only type afaik that are like
this so they are something of a special case.  There *was* a binary
wire format change for timestamps some time back iirc that was
unrelated to the int/float property.  They are unlikely to change
again unless the server's internal representation changes.

Small aside about timestamps: aside from bytea they stand to benefit
the most out of all the common types by moving to binary, especially
if you are moving them to/from something like a C struct tm on the
client.  int, float, etc are hardly noticeable and barely worth the
trouble.

Long term, imnsho significant portions of the type library on the
server should be abstracted out into a library that (optionally) the
client and the server share, with the client portions wrapped by
libpqtypes (which then becomes a simple sytnax extension to libpq),
the not frequently mentioned but very excellent ecpg, and other
drivers like php, Psycopg, etc.

merlin

pgsql-general by date:

Previous
From: Andre Lopes
Date:
Subject: Re: Transactions and ID's generated by triggers
Next
From: Merlin Moncure
Date:
Subject: Re: Hot Standby - ERROR: canceling statement due to conflict with recovery