This is similar to the same patch as I submitted Thursday, and hopefully
withdrew in time after a response was made. I have repeated the description
with appropiate changes for ease of reference.
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>?
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.
This isn't a bug fix and is therefore for 7.3 not 7.2.2
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
