From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inefficient handling of LO-restore + Patch |
Date: | 2002-04-24 18:24:48 |
Message-ID: | Pine.LNX.4.30.0204241417010.682-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> This could usefully be combined with the nearby thread about recording
> configuration options (started by Thomas). I'd be inclined to make it
> a low-footprint affair where you do something like
>
> select compilation_options();
>
> and you get back a long textual list of var=value settings, say
>
> VERSION=7.3devel
> PLATFORM=hppa-hp-hpux10.20, compiled by GCC 2.95.3
> BLCKSZ=8192
> MULTIBYTE=yes
> etc etc etc etc
This assumes that compilation options only matter in the server and that
only SQL users would be interested in them. In fact, compilation options
affect client and utility programs as well, and it's not unusual to have a
wild mix (if only unintentional).
IMHO, the best place to put this information is in the version output, as
in:
$ ./psql --version
psql (PostgreSQL) 7.3devel
contains support for: readline
An SQL interface in addition to that would be OK, too. But let's not dump
everything into one SHOW command.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-24 18:28:06 | Re: Parser translations and schemas |
Previous Message | Vince Vielhaber | 2002-04-24 18:20:23 | Re: Vote on SET in aborted transaction |