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: Pine.LNX.4.21.0205182223350.601-100000@ponder.fairway2k.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces pgsql-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
Director

---
Logictree Systems Limited
Computer Consultants

In response to

Responses

Browse pgsql-hackers by date

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

Browse pgsql-interfaces by date

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

Browse pgsql-patches by date

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