queriing the version of libpq
With 9.0 there is the new hex encoding for BYTEA, which is activated by
default.
libpq BEFORE 9.0 are not able to decode that encoding.
I am programming with Python, using psycopg2. When psycopg2 is linked with
libpq 9.0, everything works fine with hex-encoding; if psycopg2 is linked
with libpq < 9.0, decoding hex-encoded bytea fails (it stays hexencoded).
This happens because in default configuration psycopg2 calls the
libpq-decode-encoded-bytea function (which is the way it should be done).
Now I would love to have an additional check "is the used psycopg2 linked to
an advanced-enough libpq", to be able to set bytea_output to 'escape' if the
libpq is not worthy.
My question: Which way is available to query the linked libpq version?
My other option is to select 'something_that_gets_casted_to_bytea'::bytea,
and check the return value. BUT that requires a round-trip to the server....
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
On Tue, Oct 5, 2010 at 09:33, Massa, Harald Armin <chef@ghum.de> wrote:
With 9.0 there is the new hex encoding for BYTEA, which is activated by
default.
libpq BEFORE 9.0 are not able to decode that encoding.
I am programming with Python, using psycopg2. When psycopg2 is linked with
libpq 9.0, everything works fine with hex-encoding; if psycopg2 is linked
with libpq < 9.0, decoding hex-encoded bytea fails (it stays hexencoded).
This happens because in default configuration psycopg2 calls the
libpq-decode-encoded-bytea function (which is the way it should be done).
Now I would love to have an additional check "is the used psycopg2 linked to
an advanced-enough libpq", to be able to set bytea_output to 'escape' if the
libpq is not worthy.
My question: Which way is available to query the linked libpq version?
My other option is to select 'something_that_gets_casted_to_bytea'::bytea,
and check the return value. BUT that requires a round-trip to the server....
You can try calling PQconninfoParse() on a connectino string that has
applicationname= in it. That will fail on anything pre-9.0. Assuming
there's a way to access that function through psycopg2.
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
My question: Which way is available to query the linked libpq version?
That's information your driver should be supplying. For example, in
Perl (DBD::Pg), you would say
if ($dbh->{pg_lib_version} >= 90000) {
I'd raise a bug with psycopg2 if it does not provide that information.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201010051030
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkyrNskACgkQvJuQZxSWSsiW7wCfYge62y175Xtsk4drGbnt7UU5
0R4Ani1gxDhNA0xdHoq+xxxROjuC4wh+
=n33y
-----END PGP SIGNATURE-----
On Tue, Oct 5, 2010 at 16:32, Greg Sabino Mullane <greg@turnstep.com> wrote:
My question: Which way is available to query the linked libpq version?
That's information your driver should be supplying. For example, in
Perl (DBD::Pg), you would sayif ($dbh->{pg_lib_version} >= 90000) {
I'd raise a bug with psycopg2 if it does not provide that information.
How does the driver figure it out?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
if ($dbh->{pg_lib_version} >= 90000) {
I'd raise a bug with psycopg2 if it does not provide that information.
How does the driver figure it out?
DBD::Pg parses pg_config --version, then passes the information
to the C programs for directive fiddling. I certainly hope
other drivers are doing the same, as libpq varies across
major versions a good deal.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201010051132
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkyrRR8ACgkQvJuQZxSWSsgHmwCfaAPXXA1YCZ6OgOjyis6uKVmz
HvoAnj42290eDAGO+HDsGVZvOAqwEXeR
=P8XV
-----END PGP SIGNATURE-----
On 5 October 2010 16:33, Greg Sabino Mullane <greg@turnstep.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160if ($dbh->{pg_lib_version} >= 90000) {
I'd raise a bug with psycopg2 if it does not provide that information.
How does the driver figure it out?
DBD::Pg parses pg_config --version, then passes the information
to the C programs for directive fiddling. I certainly hope
other drivers are doing the same, as libpq varies across
major versions a good deal.
I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.
--
Regards,
Peter Geoghegan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.
Yeah, I'm familiar with that (I wrote it :) but it's not useful
here for two reasons:
1) It's not available on older versions
2) It returns the *target* version, not the *compiled* version.
In other words, it requires an existing PGconn object.
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201010051212
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkyrTrsACgkQvJuQZxSWSsh+rACgkvzm7HFWO4X6jHy68M4lAr74
vSoAnRzG5F+pML4IQfQxCl64b3eiNbRm
=JL6x
-----END PGP SIGNATURE-----
I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.exactly that is exposed as cn.server_version property of the psycopg2
connection object; but it does not help, as a 8.4libpq happily connects to a
9.0 server... for some values of happy :)
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
On 5 October 2010 16:33, Greg Sabino Mullane <greg@turnstep.com> wrote:
How does the driver figure it out?
DBD::Pg parses pg_config --version, then passes the information
to the C programs for directive fiddling. I certainly hope
other drivers are doing the same, as libpq varies across
major versions a good deal.
I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.
The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.
We could add a PQlibpqVersion(), maybe, but it would be many years
before client code could rely on that being present.
regards, tom lane
On Tue, Oct 5, 2010 at 18:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
On 5 October 2010 16:33, Greg Sabino Mullane <greg@turnstep.com> wrote:
How does the driver figure it out?
DBD::Pg parses pg_config --version, then passes the information
to the C programs for directive fiddling. I certainly hope
other drivers are doing the same, as libpq varies across
major versions a good deal.I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.We could add a PQlibpqVersion(), maybe, but it would be many years
before client code could rely on that being present.
I think we should.
And in a small way they can already - if they check for it
dynamically, they'll know if it was 9.1 or newer at least :-) It'll be
a long time before it's *easy* to use though. But if we don't add it
now, it'll be even longer...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
We could add a PQlibpqVersion(), maybe, but it would be many years
before client code could rely on that being present.I think we should.
And in a small way they can already - if they check for it
dynamically, they'll know if it was 9.1 or newer at least :-) It'll be
a long time before it's *easy* to use though. But if we don't add it
now, it'll be even longer...
and an additional argument: Isn't it a wise decision for clients, to allways
use the newset libpq, independent of the server? As younger libpqs happily
connect to older servers AND are supposed to have less bugs.
As libpq is very small, can be statically linked into applications and there
are no license troubles, I can see no argument to use something that is not
brand new... (compared to other databases with 120megabyte clients with
longer licence restrictions than documentations...)
Or am I missing sth?
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.
Er...yes it will match exact...because we[1]DBD::Pg get the location of the
library files from pg_config as well. :) Handy little utility that.
[1]: DBD::Pg
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201010051638
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkyrjPUACgkQvJuQZxSWSsiONwCfb8t30qkOBSKmMYDz2qL0mXIp
Xp4AoM2pQIQzUOSx4r8ZPdzNp/lA2Ar3
=1Ano
-----END PGP SIGNATURE-----
Hey all,
Could you call it as PQlibVersion() or even PQversion() instead of
PQlibpqVersion() ?
2010/10/5 Tom Lane <tgl@sss.pgh.pa.us>
Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
On 5 October 2010 16:33, Greg Sabino Mullane <greg@turnstep.com> wrote:
How does the driver figure it out?
DBD::Pg parses pg_config --version, then passes the information
to the C programs for directive fiddling. I certainly hope
other drivers are doing the same, as libpq varies across
major versions a good deal.I would imagine that most libpq wrapping drivers use libpq's
PQserverVersion(), which returns an integer that looks like 90000.The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.We could add a PQlibpqVersion(), maybe, but it would be many years
before client code could rely on that being present.regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
// Dmitriy.
On Tue, Oct 5, 2010 at 22:39, Greg Sabino Mullane <greg@turnstep.com> wrote:
The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.Er...yes it will match exact...because we[1] get the location of the
library files from pg_config as well. :) Handy little utility that.
How do you get pg_config to tell you which of the multiple versions of
libpq that may be installed on the machine you are actually linking
against?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Er...yes it will match exact...because we[1] get the location of the
library files from pg_config as well. :) Handy little utility that.How do you get pg_config to tell you which of the multiple versions of
libpq that may be installed on the machine you are actually linking
against?
Not sure what you mean. pg_config *drives* the compilation and linking,
we don't blindly compile and simply take pg_config's word for it.
pg_config --libdir and pg_config --includedir.
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201010051651
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkyrkB0ACgkQvJuQZxSWSsh4OACglNyrdKgf1jk5op7yzBw1Mh4M
sFUAnjiWVUDjNmJbNRnsuumZxzZvxQCT
=ig1E
-----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
The real problem is that neither of these can be trusted to tell you the
*library* version. PQserverVersion() is something else altogether,
and I wouldn't want to assume that pg_config exactly matches the library
you're linked to --- if it's even present at all.
Er...yes it will match exact...because we[1] get the location of the
library files from pg_config as well. :) Handy little utility that.
[ shrug... ] It's not at all hard to think of scenarios where that will
give you misleading results, even granted that you're willing to fall
over when pg_config isn't present. But regardless of that, the
technique simply isn't available to ordinary C code using the standard
dynamic linker.
regards, tom lane
On Tue, Oct 5, 2010 at 22:53, Greg Sabino Mullane <greg@turnstep.com> wrote:
Er...yes it will match exact...because we[1] get the location of the
library files from pg_config as well. :) Handy little utility that.How do you get pg_config to tell you which of the multiple versions of
libpq that may be installed on the machine you are actually linking
against?Not sure what you mean. pg_config *drives* the compilation and linking,
we don't blindly compile and simply take pg_config's word for it.
pg_config --libdir and pg_config --includedir.
But that's build-time, not run-time.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Not sure what you mean. pg_config *drives* the compilation and linking,
we don't blindly compile and simply take pg_config's word for it.
pg_config --libdir and pg_config --includedir.
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)
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201010060816
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkysaKQACgkQvJuQZxSWSsg0uACg78/o1brlOO4RtNi6U+O6noAG
PCYAn1dgpW8A/+BIOjNkhXygc16tyB3R
=YN9u
-----END PGP SIGNATURE-----
On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane <greg@turnstep.com> wrote:
Not sure what you mean. pg_config *drives* the compilation and linking,
we don't blindly compile and simply take pg_config's word for it.
pg_config --libdir and pg_config --includedir.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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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.
regards, tom lane
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/
On tis, 2010-10-05 at 09:33 +0200, Massa, Harald Armin wrote:
Now I would love to have an additional check "is the used psycopg2
linked to an advanced-enough libpq", to be able to set bytea_output to
'escape' if the libpq is not worthy.
This is really something that psycopg2 should work out for you. I
suggest you take up a discussion on this on their mailing list.
On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
This is really something that psycopg2 should work out for you. I
suggest you take up a discussion on this on their mailing list.
...which is down over the last 3 weeks or so:
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Oct 7, 2010, at 5:34 AM, Devrim GÜNDÜZ wrote:
On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
This is really something that psycopg2 should work out for you. I
suggest you take up a discussion on this on their mailing list....which is down over the last 3 weeks or so:
In addition, I posted a patch for 9.0 support which was supposed to be rolled in to psycopg2 weeks ago. Now I am stuck pushing my own psycopg2 egg around. The psycopg2 project is too reliant on one person (who has trouble managing his servers)- I wish he would move the project to a public project management service.
I also remember a discussion on the poor state of postgresql drivers for python and which driver the PostgreSQL project should endorse- it looks like the situation has not improved. Here's the thread: http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php
Cheers,
M
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.[...]
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).So there are quite many arguments for adding a
PQlibpqVersion()
to libpq, yeah? Do you think you will do it, Magnus?
[updates: the other "got bitten by the BYTEA-encoding-change"-thread is
connected to this....]
Best wishes,
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
Hey Massa,
Again, I suggest PQlibVersion() or PQversion() instead of PQlibpqVersion().
Why this "pq" redundancy in name? Waste of bytes.
2010/10/14 Massa, Harald Armin <chef@ghum.de>
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.[...]
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).So there are quite many arguments for adding a
PQlibpqVersion()
to libpq, yeah? Do you think you will do it, Magnus?
[updates: the other "got bitten by the BYTEA-encoding-change"-thread is
connected to this....]Best wishes,
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
--
// Dmitriy.
Dmitriy,
Again, I suggest PQlibVersion() or PQversion() instead of PQlibpqVersion().
Why this "pq" redundancy in name? Waste of bytes.
the first PQ qualifies the name-space "those are PostgresQl functions".
the library is called libpq, and we are explicitly asking for the version of
libpq; not of any other library that may or may not be connected with libpq
(in some compilations there is linkage to some system libraries, which have
versions of their own. in other implementations there are wrappers around
the libpq-libraray, which have their own version to. Oh, and there is
open-ssl which may be mixed into the whole party)
So 2 bytes of source-code / linker redundancy in times where smartphones
sport 12Gigabyte should be payed....
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
2010/10/14 Massa, Harald Armin <chef@ghum.de>
Dmitriy,
Again, I suggest PQlibVersion() or PQversion() instead of
PQlibpqVersion().Why this "pq" redundancy in name? Waste of bytes.
the first PQ qualifies the name-space "those are PostgresQl functions".
the library is called libpq, and we are explicitly asking for the version
of libpq; not of any other library that may or may not be connected with
libpq
If "PQ" is "namespace", so PQlibVersion() will never conflict with other
libraries.
(in some compilations there is linkage to some system libraries, which have
versions of their own. in other implementations there are wrappers around
the libpq-libraray, which have their own version to. Oh, and there is
open-ssl which may be mixed into the whole party)So 2 bytes of source-code / linker redundancy in times where smartphones
sport 12Gigabyte should be payed....I don't worry about source-code or linker. I want correctness.
Why libpq does not have PQlibpqConnect() ? How about other libraries linked
to libpq ?
Waste of bytes.
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
--
// Dmitriy.
A.M. wrote:
On Oct 7, 2010, at 5:34 AM, Devrim G?ND?Z wrote:
On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
This is really something that psycopg2 should work out for you. I
suggest you take up a discussion on this on their mailing list....which is down over the last 3 weeks or so:
In addition, I posted a patch for 9.0 support which was supposed to be
rolled in to psycopg2 weeks ago. Now I am stuck pushing my own psycopg2
egg around. The psycopg2 project is too reliant on one person (who has
trouble managing his servers)- I wish he would move the project to a
public project management service.I also remember a discussion on the poor state of postgresql drivers
for python and which driver the PostgreSQL project should endorse- it
looks like the situation has not improved. Here's the thread:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php
The python driver situation did improve, for a while. :-|
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
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?
happen as in "an addition of a function to libpq to query its version
without a server roundtrip AFTER libpq has been linked into sth has
been decided for / against"
Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare
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 application can >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/
Attachments:
pqlibversion.patchtext/x-patch; charset=US-ASCII; name=pqlibversion.patchDownload
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
***************
*** 5359,5364 **** void *PQresultAlloc(PGresult *res, size_t nBytes);
--- 5359,5399 ----
</listitem>
</varlistentry>
+ <varlistentry id="libpq-pqlibversion">
+ <term>
+ <function>PQlibVersion</function>
+ <indexterm>
+ <primary>PQlibVersion</primary>
+ <seealso>PQserverVersion</seealso>
+ </indexterm>
+ </term>
+
+ <listitem>
+ <para>
+ Return the version of <productname>libpq</> that is being used.
+ <synopsis>
+ int PQlibVersion(void);
+ </synopsis>
+ </para>
+
+ <para>
+ The result value of this function can be used to determine if
+ a specific function is available in the currently used version
+ of libpq.
+ </para>
+
+ <note>
+ <para>
+ This function appeared in <productname>PostgreSQL</> version 9.1, so
+ it cannot be used to detect required functions in earlier version.
+ Usage of this function will make the application require version
+ 9.1 or newer even if no actual funcionality from this version
+ is required.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect1>
*** a/src/interfaces/libpq/exports.txt
--- b/src/interfaces/libpq/exports.txt
***************
*** 159,161 **** PQconnectdbParams 156
--- 159,162 ----
PQconnectStartParams 157
PQping 158
PQpingParams 159
+ PQlibVersion 160
*** a/src/interfaces/libpq/fe-misc.c
--- b/src/interfaces/libpq/fe-misc.c
***************
*** 66,71 **** static int pqSocketCheck(PGconn *conn, int forRead, int forWrite,
--- 66,85 ----
time_t end_time);
static int pqSocketPoll(int sock, int forRead, int forWrite, time_t end_time);
+ /*
+ * PQlibVersion: return the libpq version number
+ */
+ int
+ PQlibVersion(void)
+ {
+ /*
+ * This number is updated by tools/version_stamp.pl, do not
+ * edit manually.
+ */
+ #define LOCAL_PG_VERSION_NUM 90100
+ return LOCAL_PG_VERSION_NUM;
+ #undef LOCAL_PG_VERSION_NUM
+ }
/*
* fputnbytes: print exactly N bytes to a file
*** a/src/interfaces/libpq/libpq-fe.h
--- b/src/interfaces/libpq/libpq-fe.h
***************
*** 547,552 **** extern int lo_export(PGconn *conn, Oid lobjId, const char *filename);
--- 547,555 ----
/* === in fe-misc.c === */
+ /* Get the version of the libpq library in use */
+ extern int PQlibVersion(void);
+
/* Determine length of multibyte encoded char at *s */
extern int PQmblen(const char *s, int encoding);
*** a/src/tools/version_stamp.pl
--- b/src/tools/version_stamp.pl
***************
*** 88,93 **** sed_file("src/include/pg_config.h.win32",
--- 88,96 ----
"-e 's/#define PG_VERSION \".*\"/#define PG_VERSION \"$fullversion\"/' " .
"-e 's/#define PG_VERSION_NUM .*/#define PG_VERSION_NUM $padnumericversion/'");
+ sed_file("src/interfaces/libpq/fe-misc.c",
+ "-e 's/#define LOCAL_PG_VERSION_NUM .*/#define LOCAL_PG_VERSION_NUM $padnumericversion/'");
+
sed_file("src/interfaces/libpq/libpq.rc.in",
"-e 's/FILEVERSION [0-9]*,[0-9]*,[0-9]*,0/FILEVERSION $major1,$major2,$numericminor,0/' " .
"-e 's/PRODUCTVERSION [0-9]*,[0-9]*,[0-9]*,0/PRODUCTVERSION $major1,$major2,$numericminor,0/' " .
Magnus, thats great ! And name PQlibVersion is correct ! Thanks.
2010/12/16 Magnus Hagander <magnus@hagander.net>
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 application can >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/--
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 application can >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 application can >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, namelyif (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/
Attachments:
libpq_version.difftext/x-patch; charset=US-ASCII; name=libpq_version.diffDownload
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index c502439..a776df4 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -5359,6 +5359,50 @@ void *PQresultAlloc(PGresult *res, size_t nBytes);
</listitem>
</varlistentry>
+ <varlistentry id="libpq-pqlibversion">
+ <term>
+ <function>PQlibVersion</function>
+ <indexterm>
+ <primary>PQlibVersion</primary>
+ <seealso>PQserverVersion</seealso>
+ </indexterm>
+ </term>
+
+ <listitem>
+ <para>
+ Return the version of <productname>libpq</> that is being used.
+<synopsis>
+int PQlibVersion(void);
+</synopsis>
+ </para>
+
+ <para>
+ The result value of this function can be used to determine, at
+ runtime, if a specific functionality is available in the currently
+ loaded version of libpq. Examples of this include whether specific
+ connection options are available for <function>PQconnectdb</> and
+ the new <type>bytea</> encoding in PostgreSQL 9.0 that requires
+ libpq version 9.0 or later to work.
+ </para>
+
+ <para>
+ The number is formed by converting the major, minor, and revision
+ numbers into two-decimal-digit numbers and appending them together.
+ For example, version 9.1 will be returned as 90100, and version
+ 9.1.2 will be returned as 90102 (leading zeroes are not shown).
+ </para>
+
+ <note>
+ <para>
+ This function appeared in <productname>PostgreSQL</> version 9.1, so
+ it cannot be used to detect required functionality in earlier
+ versions, since linking to it will create a load time dependency
+ on version 9.1.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect1>
diff --git a/src/interfaces/libpq/exports.txt b/src/interfaces/libpq/exports.txt
index a6c73af..1af8df6 100644
--- a/src/interfaces/libpq/exports.txt
+++ b/src/interfaces/libpq/exports.txt
@@ -159,3 +159,4 @@ PQconnectdbParams 156
PQconnectStartParams 157
PQping 158
PQpingParams 159
+PQlibVersion 160
diff --git a/src/interfaces/libpq/fe-misc.c b/src/interfaces/libpq/fe-misc.c
index 24ab7cf..999f60b 100644
--- a/src/interfaces/libpq/fe-misc.c
+++ b/src/interfaces/libpq/fe-misc.c
@@ -66,6 +66,14 @@ static int pqSocketCheck(PGconn *conn, int forRead, int forWrite,
time_t end_time);
static int pqSocketPoll(int sock, int forRead, int forWrite, time_t end_time);
+/*
+ * PQlibVersion: return the libpq version number
+ */
+int
+PQlibVersion(void)
+{
+ return PG_VERSION_NUM;
+}
/*
* fputnbytes: print exactly N bytes to a file
diff --git a/src/interfaces/libpq/libpq-fe.h b/src/interfaces/libpq/libpq-fe.h
index 271afed..6075ea8 100644
--- a/src/interfaces/libpq/libpq-fe.h
+++ b/src/interfaces/libpq/libpq-fe.h
@@ -547,6 +547,9 @@ extern int lo_export(PGconn *conn, Oid lobjId, const char *filename);
/* === in fe-misc.c === */
+/* Get the version of the libpq library in use */
+extern int PQlibVersion(void);
+
/* Determine length of multibyte encoded char at *s */
extern int PQmblen(const char *s, int encoding);
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/
#include <pg_config.h>
/usr/include/pg_config-x86_64.h:#define PG_VERSION "9.6.9"
/usr/include/pg_config-x86_64.h:#define PG_VERSION_NUM 90609
/usr/include/pg_config-x86_64.h:#define PG_VERSION_STR "PostgreSQL 9.6.9 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 7.3.1 20180303 (Red Hat
7.3.1-5), 64-bit"
I also have source for 8.4 and its there too.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html