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

From Peter Eisentraut
Subject Re: Inefficient handling of LO-restore + Patch
Date
Msg-id Pine.LNX.4.30.0204241417010.682-100000@peter.localdomain
Whole thread Raw
In response to Re: Inefficient handling of LO-restore + Patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inefficient handling of LO-restore + Patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmx.net



pgsql-hackers by date:

Previous
From: "Igor Kovalenko"
Date:
Subject: Re: "make report"
Next
From: Vince Vielhaber
Date:
Subject: Re: Vote on SET in aborted transaction