Re: querying the version of libpq - Mailing list pgsql-general

From Magnus Hagander
Subject Re: querying the version of libpq
Date
Msg-id AANLkTi=JpmHkERWg8UwT8stHEwwTzPdvyY68iu+Tpn18@mail.gmail.com
Whole thread Raw
In response to Re: querying the version of libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: querying the version of libpq  ("Massa, Harald Armin" <chef@ghum.de>)
List pgsql-general
On Tue, Oct 5, 2010 at 18:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
>> On 5 October 2010 16:33, Greg Sabino Mullane <greg@turnstep.com> wrote:
>>>> How does the driver figure it out?
>>>
>>> DBD::Pg parses pg_config --version, then passes the information
>>> to the C programs for directive fiddling. I certainly hope
>>> other drivers are doing the same, as libpq varies across
>>> major versions a good deal.
>
>> I would imagine that most libpq wrapping drivers use libpq's
>> PQserverVersion(), which returns an integer that looks like 90000.
>
> The real problem is that neither of these can be trusted to tell you the
> *library* version.  PQserverVersion() is something else altogether,
> and I wouldn't want to assume that pg_config exactly matches the library
> you're linked to --- if it's even present at all.
>
> We could add a PQlibpqVersion(), maybe, but it would be many years
> before client code could rely on that being present.

I think we should.

And in a small way they can already - if they check for it
dynamically, they'll know if it was 9.1 or newer at least :-) It'll be
a long time before it's *easy* to use though. But if we don't add it
now, it'll be even longer...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: Trying to figure out why these queries are so slow
Next
From: Jeff Ross
Date:
Subject: Re: psql \q hang