Re: Inefficient handling of LO-restore + Patch

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

In response to

Responses

Browse pgsql-hackers by date

  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