Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] libpgtcl - backend version information

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org,PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [INTERFACES] libpgtcl - backend version information
Date: 2002-05-18 21:41:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfacespgsql-patches
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.

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

Logictree Systems Limited
Computer Consultants

In response to


pgsql-hackers by date

Next:From: Joe ConwayDate: 2002-05-18 22:16:03
Subject: Re: Set-returning function syntax
Previous:From: Bear GilesDate: 2002-05-18 21:11:39
Subject: Re: SASL, compression?

pgsql-patches by date

Next:From: Neil ConwayDate: 2002-05-18 22:57:25
Subject: libpq++ fixes
Previous:From: Tom LaneDate: 2002-05-18 20:11:59
Subject: Re: [INTERFACES] libpgtcl - backend version information patch

pgsql-interfaces by date

Next:From: C. MajDate: 2002-05-19 00:37:11
Subject: Re: [HACKERS] libpgtcl - backend version information
Previous:From: Tom LaneDate: 2002-05-18 20:11:59
Subject: Re: [INTERFACES] libpgtcl - backend version information patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group