On Wed, Oct 6, 2010 at 15:54, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Magnus Hagander <magnus@xxxxxxxxxxxx> writes: >> On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane <greg@xxxxxxxxxxxx> 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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
