*new* libpgtcl - backend version information patch

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: pgsql-patches(at)postgresql(dot)org
Cc: pgsql-interfaces(at)postgresql(dot)org, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: *new* libpgtcl - backend version information patch
Date: 2002-05-18 18:52:27
Message-ID: Pine.LNX.4.21.0205181942130.601-100000@ponder.fairway2k.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces pgsql-patches

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-18 19:02:17 Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Previous Message Bear Giles 2002-05-18 18:38:29 pq_eof() broken with SSL

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2002-05-18 20:11:59 Re: [INTERFACES] libpgtcl - backend version information patch
Previous Message Nigel J. Andrews 2002-05-18 18:11:40 Re: [INTERFACES] libpgtcl - backend version information patch

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-05-18 19:02:17 Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Previous Message Nigel J. Andrews 2002-05-18 18:11:40 Re: [INTERFACES] libpgtcl - backend version information patch