At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>And how about getting database internals via SQL-functions - e.g. getting 
>BLCSIZE, LOBBLCSIZE?

ISTM that there would be some merit in making a selection of compile-time 
options available via SQL. Is this worth considering?




Wed, 24 Apr 2002 15:58:15 +1000
Philip Warner <pjw@rhyme.com.au>
Re: Inefficient handling of LO-restore + Patch 
Philip Warner <pjw@rhyme.com.au> writes:
> At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>> And how about getting database internals via SQL-functions - e.g. getting 
>> BLCSIZE, LOBBLCSIZE?

> ISTM that there would be some merit in making a selection of compile-time 
> options available via SQL. Is this worth considering?

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 would solve the diagnostic need as-is, and it doesn't seem
unreasonable to me to expect applications to look through the output
for a particular line if they need to get the state of a specific
configuration option.  It's also trivial to extend/modify as the set
of options changes over time.

			regards, tom lane

Wed, 24 Apr 2002 10:30:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficient handling of LO-restore + Patch 
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


Wed, 24 Apr 2002 14:24:48 -0400 (EDT)
Peter Eisentraut <peter_e@gmx.net>
Re: Inefficient handling of LO-restore + Patch 
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

Wed, 24 Apr 2002 18:13:28 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficient handling of LO-restore + Patch 
On Wed, Apr 24, 2002 at 06:13:28PM -0400, Tom Lane wrote:
> 
> 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.

I like the way perl handles this, for example

perl -MExtUtils::Embed -e ccopts

for options to cc used when compiling(-I and stuff) and

perl -MExtUtils::Embed -e ldopts

for options to ld used when compiling(-L and stuff).
I think it would be really nice if we could have psql to ask its libpq to
spew out something similiar. Then you could do stuff like

cc -o ex ex.c `psql -ccopts -ldopts` 

and not having to worry about where the libraries are.

-- Magnus

Fri, 3 May 2002 14:20:47 +0200
Magnus Enbom <dot@rockstorm.se>
Re: Inefficient handling of LO-restore + Patch