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/