Thread: Re: [GENERAL] queriing the version of libpq
On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin <chef@ghum.de> wrote: >>> My question: Which way is available to query the linked libpq version? > >> But it does outline that fact that it wouldn't suck to have a >function in libpq returning the version so that applicationcan >check this at runtime - clearly it would also be useful when >being linked "through" something like psycopg2. > > did there something happen? Stuck in a local git branch. I've rebased on current and added docs, see attachment. (moving to hackers as well) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Attachment
Magnus, thats great ! And name PQlibVersion is correct ! Thanks.
--
// Dmitriy.
2010/12/16 Magnus Hagander <magnus@hagander.net>
On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin <chef@ghum.de> wrote:Stuck in a local git branch. I've rebased on current and added docs,
>>> My question: Which way is available to query the linked libpq version?
>
>> But it does outline that fact that it wouldn't suck to have a >function in libpq returning the version so that application can >check this at runtime - clearly it would also be useful when >being linked "through" something like psycopg2.
>
> did there something happen?
see attachment.
(moving to hackers as well)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
// Dmitriy.
Magnus Hagander <magnus@hagander.net> writes: > But it does outline that fact that it wouldn't suck to have a >function �in libpq returning the version so that applicationcan >check this at �runtime - clearly it would also be useful when >being linked "through" something like psycopg2. > Stuck in a local git branch. I've rebased on current and added docs, > see attachment. Ick. Please get rid of that extra version number. There is no reason not to use PG_VERSION_NUM. The documentation needs further thought too: grammar needs work, and the format of the result value is unspecified. But perhaps we should first recheck the premise. Exactly how will this function be useful? I don't believe it's usable in the form implied by the documentation, namely if (PQlibVersion() >= something) ... call PQspiffyNewFunction() ...else ... do something else ... because if you're trying to link against an older libpq, the link will fail before you ever get to execute. So let's have a less implausible use-case please. regards, tom lane
On Thu, Dec 16, 2010 at 17:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> But it does outline that fact that it wouldn't suck to have a >function in libpq returning the version so that applicationcan >check this at runtime - clearly it would also be useful when >being linked "through" something like psycopg2. > >> Stuck in a local git branch. I've rebased on current and added docs, >> see attachment. > > Ick. Please get rid of that extra version number. There is no reason > not to use PG_VERSION_NUM. The documentation needs further thought too: > grammar needs work, and the format of the result value is unspecified. Gah. i was thinking "need to avoid pulling in pg_config.h since it's exposed to clients".. But that's only the header. D'uh. Will fix. > But perhaps we should first recheck the premise. Exactly how will this > function be useful? I don't believe it's usable in the form implied by > the documentation, namely > > if (PQlibVersion() >= something) > ... call PQspiffyNewFunction() ... > else > ... do something else ... > > because if you're trying to link against an older libpq, the link will > fail before you ever get to execute. So let's have a less implausible > use-case please. Look back at the very start of the thread. Detecting behavior changes (in this case with bytea encoding). The other one would be if there are options to a call that can be different. For example, knowing which options you can pass to PQconnect() without getting an error. (Yes, you can manually call PQconninfoParse() and check it out, but that's a lot uglier IMO). And it *could* be used in exactly the case you're outlining as long as you load the function dynamically. Which could most definitely be useful for a *driver* to be able to do - and I'm sure some programs as well. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes: > On Thu, Dec 16, 2010 at 17:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> because if you're trying to link against an older libpq, the link will >> fail before you ever get to execute. �So let's have a less implausible >> use-case please. > Look back at the very start of the thread. OK, but let's document those examples instead. regards, tom lane
> > And it *could* be used in exactly the case you're outlining as long as > you load the function dynamically. Detecting the presence of a function does not require a version number. If the symbol is in the library, use it. The only reason the version number would come into play is if you were attempting to detect behavior differences. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
On Thu, Dec 16, 2010 at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Thu, Dec 16, 2010 at 17:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> because if you're trying to link against an older libpq, the link will >>> fail before you ever get to execute. So let's have a less implausible >>> use-case please. > >> Look back at the very start of the thread. > > OK, but let's document those examples instead. Something like this better? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Attachment
On Mon, Dec 20, 2010 at 16:48, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Dec 16, 2010 at 17:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Magnus Hagander <magnus@hagander.net> writes: >>> On Thu, Dec 16, 2010 at 17:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> because if you're trying to link against an older libpq, the link will >>>> fail before you ever get to execute. So let's have a less implausible >>>> use-case please. >> >>> Look back at the very start of the thread. >> >> OK, but let's document those examples instead. > > Something like this better? I got some help from Bruce to look over the grammar in the docs (and fix the broken ones), and have now applied and pushed this. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/