Re: querying the version of libpq

On Wed, Oct 6, 2010 at 15:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>>>> 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.
>
> The problem here is that you might actually be *running* with a
> different version of libpq than you built against.  This is actually
> highly likely if you distribute an executable that dynamically links
> to a shared library at runtime.  And the dynamic linker will take any
> version of libpq.so that has the same major number, meaning that you
> cannot assume that it's not 8.4 just because you built against 9.0.

Uh, that's what I was saying. The build version is quite irrelevant for that.

Not to mention when you're on windows (and I dunno if any other
platforms are like *that*), where they're all libpq.dll and we'll
happily take *any* other libpq.dll (even an older one, but that will
give you an error if you're actually using any functions not present
in it).

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