Обсуждение: Re: [HACKERS] [INTERFACES] libpgtcl - backend version information patch

Поиск
Список
Период
Сортировка

Re: [HACKERS] [INTERFACES] libpgtcl - backend version information patch

От
Tom Lane
Дата:
"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

Re: [HACKERS] [INTERFACES] libpgtcl - backend version information

От
"Nigel J. Andrews"
Дата:
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