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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse psycopg by date

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