From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
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 22:13:28 |
Message-ID: | 19344.1019686408@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> select compilation_options();
> 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).
Good point. It'd be worthwhile to have some way of extracting such
information from the clients as well.
> 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
Is that sufficient? The clients probably are not affected by quite as
many config options as the server, but they still have a nontrivial
list. (Multibyte, SSL, Kerberos come to mind at once.) I'd not like
to see us assume that a one-line output format will do the job.
A way to interrogate the libpq being used by psql might be good too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-04-24 22:46:10 | PostgreSQL index usage discussion. |
Previous Message | Francisco Jr. | 2002-04-24 21:15:53 | Re: Implement a .NET Data |