Re: Binary params in libpq

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Binary params in libpq
Date: 2011-02-28 14:42:36
Message-ID: AANLkTi=7=xDZVR1SrqszfW4J5FZSZ9vQRsKqp7-TFLCK@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Feb 27, 2011 at 7:39 PM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2011-02-28 15:00:39 Re: Hot Standby - ERROR: canceling statement due to conflict with recovery
Previous Message Borek Lupomesky 2011-02-28 14:37:51 Permission denied when inserting