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

Re: Using real libpq parameters

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: "P(dot) Christeas" <p_christ(at)hol(dot)gr>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: Using real libpq parameters
Date: 2011-02-27 17:49:23
Message-ID: AANLkTim7ft6n4YugJu0Xr+fdrYWOndzEZfzT=4tcBT6F@mail.gmail.com (view raw or flat)
Thread:
Lists: psycopg
On Sun, Feb 27, 2011 at 10:30 AM, P. Christeas <p_christ(at)hol(dot)gr> wrote:

>  5. libpqtypes doesn't seem to help as you suggested. It does text->net-bin
> adaptations, which we don't need, since Python internal representation is
> already binary. We want a bin->net-bin library (where net-bin is the network
> Postgres-native format of data, heavily dependent on server's version)..

I have re-(re-re-)read the comments about the binary types in the
libpq documentation, and it's not as dire as I thought it was:

"""
Values passed in binary format require knowledge of the internal
representation expected by the backend. For example, integers must be
passed in network byte order. Passing numeric values requires
knowledge of the server storage format, as implemented in
src/backend/utils/adt/numeric.c::numeric_send() and
src/backend/utils/adt/numeric.c::numeric_recv().
"""

So *it is* an implementation leak, but it doesn't promise breakage at
every version. I will ask for further details on the postgres MLs to
try to get a better picture.

> OTOH, reading the code of libpqtypes /could/ help us write ourselves similar
> adapters.

This is true of course: even if we decided not to use libpqtypes
there's surely a lot to learn from it.

-- Daniele

In response to

psycopg by date

Next:From: Daniele VarrazzoDate: 2011-02-27 23:35:43
Subject: Re: Using real libpq parameters
Previous:From: A.M.Date: 2011-02-27 16:11:25
Subject: Re: Using real libpq parameters

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