Re: [HACKERS] libpgtcl - backend version information

Please note this posting was to HACKERS, INTERFACES, and PATCHES, but
I'm only subscribed to INTERFACES so that's where this message is going.

On Sat, 18 May 2002, Nigel J. Andrews wrote:

> On Sat, 18 May 2002, Tom Lane wrote:
>
> > "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)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.

Yes it was I who concurred, for exactly the reasons Nigel offered.
Putting that functionality into the TCL layer would help more than just
pgaccess. I program in PHP a lot and while it provides the basic
functions of the C api there's also several more functions for returning
a variety of information on the connected database, at least with
postgresql and mysql.

As far as pgaccess goes, I don't think we're looking at 7.2.2, as that
seems to be mostly a bug fix release. Maybe we should shoot for 7.3?

> 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)

I guess not many people are excited about moving this functionality any
lower. I just think with the changes that are coming up with the schema
and all you are leaving too much up to the application programmers or
the end users. I could be wrong, I haven't really been following
postgresql for too long.

--Chris

--

cmaj_at_freedomcorpse_dot_info
fingerprint 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A