I've attached a patch for libpgtcl which adds access to backend version
numbers.
This is via a new command:
pg_version <db channel> <major varname> ?<minor varname>? ?<patch varname>?
Using readonly variables rather than a command was my first choice but I
decided that it was inappropiate for the library to start assigning global
variable(s) when that's really the applications job and the command interface
is consistent with the rest of the interface.
Obviously, backend version numbers are specific to a particular connection. So
I've created a new data structure, to keep the information as a distinct unit,
and added an instance of the new structure to the Pg_ConnectionId type. The
version information is retrieved from the given connection on first use of
pg_version and cached in the new data structure for subsequent accesses.
In addition to filling the named variables in the callers scope with version
numbers/strings the command returns the complete string as returned by
version(). It's not possible to turn this return off at the moment but I don't
see it as a problem since normal methods of stopping unwanted values returned
from procedures can be applied in the application if required.
Perhaps the most significant change is that I've increased the package's
version number from 1.3 to 1.4. This will adversly effect anyone using an
application that requires a specific version of the package where their
postgres installation is updated but their application has not been. I can't
imagine there are many applications out there using the package management
features of TCL though.
I envisage this patch applied to 7.3 tip and to 7.2 for the 7.2.2 release
mentioned a couple of days ago. The only problem with doing this for 7.2 that I
can see is where people doing the 'package -exact require Pgtcl 1.x' thing, and
how many of those are there? Even PgAccess doesn't use that.
Note for commiter et al,, this patch also includes one change made in 7.3devel
and not 7.2.1. That is where a test of the return value from a Tcl_SetVar call
has been corrected from a test against TCL_OK to NULL. This is correct and
should be applied to the 7.2 branch in my view, however, I do not know if this
has already been applied there so something to watch out for.
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
