Thread: Re: [INTERFACES] libpgtcl - backend version information patch
[My apolgies if this turns up in the lists twice (now three times) but my mailer claims it's been in the queue for them too long. Not sure why it thinks that since it's only a few minutes since I sent it.] On Fri, 17 May 2002, Peter Eisentraut wrote: > Nigel J. Andrews writes: > > > 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>? > > This doesn't truly reflect the way PostgreSQL version numbers are handled. > Say for 7.2.1, the "major" is really "7.2" and the minor is "1". With the > interface you proposed, the information major == 7 doesn't really convey > any useful information. Ah, oops. I'll change it. I withdraw the patch submission I made yesterday (now two days back). > > 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. > > Normally we only put bug fixes in minor releases. PgAccess may get an > exception, but bumping the version number of a library is stretching it a > little. If you're intending to use the function for PgAccess, why not > make it internal to PgAccess? That way you can tune the major/minor thing > exactly how you need it. It did occur to me this morning that having it applied for 7.2.2 was perhaps silly as it was introducing a new feature and not a bug fix. This feature could be added to PgAccess but I felt it was general enough to be placed in the interface library. I think someone else suggested such a place a couple of weeks ago also. If there is a concensus that this should be done in the application layer I'll happily drop this patch completely. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
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
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> This feature could be added to PgAccess but I felt it was general
> enough to be placed in the interface library. I think someone else
> suggested such a place a couple of weeks ago also. If there is a
> concensus that this should be done in the application layer I'll
> happily drop this patch completely.
I guess I don't quite see the point of doing this in libpgtcl,
as opposed to doing a "select version()" at the application level.
It would take only a line or two of Tcl code to do that and parse the
result of version(), so why write many lines of C to accomplish the
same thing?
regards, tom lane
On Sat, 18 May 2002, Tom Lane wrote: > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > > This feature could be added to PgAccess but I felt it was general > > enough to be placed in the interface library. I think someone else > > suggested such a place a couple of weeks ago also. If there is a > > concensus that this should be done in the application layer I'll > > happily drop this patch completely. > > I guess I don't quite see the point of doing this in libpgtcl, > as opposed to doing a "select version()" at the application level. > It would take only a line or two of Tcl code to do that and parse the > result of version(), so why write many lines of C to accomplish the > same thing? Yes, you're right. It is only a couple of lines to do the exec, error checking and parsing. Someone mentioned how it might be worth considering putting version testing into the library. I thought it a reasonable idea, something that would be reasonably be expected to reused across applications and as I'm not putting forward anything for pgaccess until it's decided what the heck is going on with it thought I'd do the libpgtcl version of it. I see the pros as: version information is accessable to all TCL applications without each having to worry about getting it, it comes ready to support multiple DB connections per application. The cons: well I don't see anything similar in the perl interface and it's not in libpq so as the other interfaces are essentially wrappers for libpq it shouldn't be in libpqtcl either, there's more C code than TCL code would take (still, I could change it to use a Tcl_eval if it's lines of code that count) -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants