Re: querying the version of libpq

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: querying the version of libpq
Date: 2010-10-06 12:25:21
Message-ID: AANLkTinc7zQCC-i9cML1H9UYzym10zt1gEjizn54sZ+6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>
>
>> Not sure what you mean. pg_config *drives* the compilation and linking,
>> we don't blindly compile and simply take pg_config's word for it.
>> pg_config --libdir and pg_config --includedir.
>
>> But that's build-time, not run-time.
>
> Correct, not sure of your point. Is this a problem? Build-time is
> what we want here (determining the libpq we were built with)

The original question was how to find this out from python, which
means at runtime.

And the pg_lib_version of DBD::Pg clearly doesn't tell you what
version of libpq it's using, only what it was built against.

As long as you have libpq 9.0, you can decode the bytea hex thingy,
irregardless of what version of libpq your <whatever other
code/library> was linked against.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2010-10-06 12:46:42 Re: Composite type operator not unique
Previous Message Trigve 2010-10-06 12:17:44 Re: Composite type operator not unique

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-10-06 12:26:51 Re: Issues with Quorum Commit
Previous Message Dimitri Fontaine 2010-10-06 12:22:00 Re: Issues with Quorum Commit