Re: RPM question: Where to put psycopg2 files

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: harald(at)2ndquadrant(dot)com
Cc: psycopg(at)postgresql(dot)org
Subject: Re: RPM question: Where to put psycopg2 files
Date: 2011-01-17 14:48:42
Message-ID: AANLkTimfxgXXW4crgHamyMbOybkkcD0W0sMS=_gj4TKy@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On Mon, Jan 17, 2011 at 2:00 PM, Harald Armin Massa
<harald(at)2ndquadrant(dot)com> wrote:
>> Bottom line is that currently only libpq 9.0 works fine to talk with a
>> 9.0 server, unless bytea_output is set to 'escape' on the server.
>>
> to add to your very correct explanation: until 9.1 it is not possible to
> identify the libpq version from a client application. Magnus committed a
> patch to provide a "query-the-libpq-version" for 9.1; which will provide
> do-less-connections-to-identify-capabilities opportunity for psycopg2.

Yes, what we currently do is to identify the libpq version at compile
time. Of course it may be a lie and at runtime we may end up with the
wrong version. But what happens now is just that we don't include the
support for certain features if not available in the libpq at compile
time (e.g. lo_truncate, to name one). If things change at runtime, you
either don't get that feature (if libpq.so is newer) or you get a nice
ImportError (if libpq.so is older). Honestly I don't know if it would
worth the hassle of adding conditional runtime import: probably not
for the current set of conditional features, they are just a few.

Connection-time queries are more related to discovering GUC settings
than libpq capabilities: the only surviving one is to get the server
default_transaction_isolation.

-- Daniele

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2011-01-17 15:01:51 Re: RPM question: Where to put psycopg2 files
Previous Message Harald Armin Massa 2011-01-17 14:00:28 Re: RPM question: Where to put psycopg2 files