Re: queriing the version of libpq
От | Magnus Hagander |
---|---|
Тема | Re: queriing the version of libpq |
Дата | |
Msg-id | AANLkTi=cPLuPn=WDf7r9APz632Pf3qyM8BbEKt5sA0Pd@mail.gmail.com обсуждение исходный текст |
Ответ на | queriing the version of libpq ("Massa, Harald Armin" <chef@ghum.de>) |
Ответы |
Re: queriing the version of libpq
|
Список | pgsql-general |
On Tue, Oct 5, 2010 at 09:33, Massa, Harald Armin <chef@ghum.de> wrote: > 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.... You can try calling PQconninfoParse() on a connectino string that has applicationname= in it. That will fail on anything pre-9.0. Assuming there's a way to access that function through psycopg2. But it does outline that fact that it wouldn't suck to have a function in libpq returning the version so that application can check this at runtime - clearly it would also be useful when being linked "through" something like psycopg2. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-general по дате отправления: