Re: RPM question: Where to put psycopg2 files
От | Daniele Varrazzo |
---|---|
Тема | Re: RPM question: Where to put psycopg2 files |
Дата | |
Msg-id | AANLkTimfxgXXW4crgHamyMbOybkkcD0W0sMS=_gj4TKy@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RPM question: Where to put psycopg2 files (Harald Armin Massa <harald@2ndQuadrant.com>) |
Ответы |
Re: RPM question: Where to put psycopg2 files
|
Список | psycopg |
On Mon, Jan 17, 2011 at 2:00 PM, Harald Armin Massa <harald@2ndquadrant.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
В списке psycopg по дате отправления: