Re: Inefficient handling of LO-restore + Patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inefficient handling of LO-restore + Patch
Date
Msg-id 19344.1019686408@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inefficient handling of LO-restore + Patch  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Inefficient handling of LO-restore + Patch  (Magnus Enbom <dot@rockstorm.se>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: "Francisco Jr."
Date:
Subject: Re: Implement a .NET Data
Next
From: mlw
Date:
Subject: PostgreSQL index usage discussion.