[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