Re: Binary params in libpq

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, 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-03-01 14:47:01
Message-ID: AANLkTin00o0aP7cbzxHwnzoNYWuUp-utNPOteTcC0t3d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Mar 1, 2011 at 8:19 AM, Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com> wrote:
> On Mon, Feb 28, 2011 at 8:42 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Sun, Feb 27, 2011 at 7:39 PM, Craig Ringer
>>> 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
>
> I don't see any libpq calls that can, at run-time, tell you things
> like what format the timestamp is and what endian-ness the server is.
> Is there something I'm missing?  The only thing I could figure out is
> to do something like 'select 123::int4' or select a known date and
> determine the nature of the server from what you get back.

You don't need to know endian-ness: it is always in network order (big
endian). As noted above, you can check datetime format with
PQparameterStatus.

Really, my advice to you and the countless others who seem to
continually want to re-engineer this problem is to either use or crib
from two libraries that have completely solved it...namely libpqtypes
and ecpg. Some of the wire formats are non-trivial to convert to C
native types.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alan Acosta 2011-03-01 15:04:02 Re: Lock ACCESS EXCLUSIVE and Select question !
Previous Message Adrian Klaver 2011-03-01 14:44:46 Re: database is bigger after dump/restore - why? (60 GB to 109 GB)