Re: [HACKERS] [GENERAL] queriing the version of libpq
On Mon, Dec 20, 2010 at 16:48, Magnus Hagander mag...@hagander.net wrote: On Thu, Dec 16, 2010 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Thu, Dec 16, 2010 at 17:07, Tom Lane t...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
On Thu, Dec 16, 2010 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Dec 16, 2010 at 17:07, Tom Lane t...@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/
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
+ functionPQlibVersion/function
+ indexterm
+ primaryPQlibVersion/primary
+ seealsoPQserverVersion/seealso
+ /indexterm
+/term
+
+listitem
+ para
+ Return the version of productnamelibpq/ 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 functionPQconnectdb/ and
+ the new typebytea/ 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 productnamePostgreSQL/ 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
PQping158
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);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin c...@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/
*** 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
+ functionPQlibVersion/function
+ indexterm
+ primaryPQlibVersion/primary
+ seealsoPQserverVersion/seealso
+ /indexterm
+ /term
+
+ listitem
+ para
+ Return the version of productnamelibpq/ 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 productnamePostgreSQL/ 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
PQping158
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/' .
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
Magnus, thats great ! And name PQlibVersion is correct ! Thanks. 2010/12/16 Magnus Hagander mag...@hagander.net On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin c...@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.
Re: [HACKERS] [GENERAL] queriing the version of libpq
Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
On Thu, Dec 16, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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, 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
Magnus Hagander mag...@hagander.net writes: On Thu, Dec 16, 2010 at 17:07, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] queriing the version of libpq
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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
