From: | "Massa, Harald Armin" <chef(at)ghum(dot)de> |
---|---|
To: | PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | queriing the version of libpq |
Date: | 2010-10-05 07:33:44 |
Message-ID: | AANLkTi=q5iTGCjtMN1hv+O4bbCbeX-cWxr0Z2uyqkaUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
With 9.0 there is the new hex encoding for BYTEA, which is activated by
default.
libpq BEFORE 9.0 are not able to decode that encoding.
I am programming with Python, using psycopg2. When psycopg2 is linked with
libpq 9.0, everything works fine with hex-encoding; if psycopg2 is linked
with libpq < 9.0, decoding hex-encoded bytea fails (it stays hexencoded).
This happens because in default configuration psycopg2 calls the
libpq-decode-encoded-bytea function (which is the way it should be done).
Now I would love to have an additional check "is the used psycopg2 linked to
an advanced-enough libpq", to be able to set bytea_output to 'escape' if the
libpq is not worthy.
My question: Which way is available to query the linked libpq version?
My other option is to select 'something_that_gets_casted_to_bytea'::bytea,
and check the return value. BUT that requires a round-trip to the server....
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2010-10-05 07:43:09 | Re: Is there a logical reason for 25P02? |
Previous Message | Arjen Nienhuis | 2010-10-05 07:26:54 | Re: Question regarding custom parser |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-10-05 08:02:47 | Re: queriing the version of libpq |
Previous Message | Rajesh Kumar Mallah | 2010-10-05 07:04:52 | Re: streaming replication question |