On Wed, Oct 6, 2010 at 15:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane <greg@turnstep.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/
