From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inefficient handling of LO-restore + Patch |
Date: | 2002-04-24 14:30:26 |
Message-ID: | 11803.1019658626@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2002-04-24 14:57:43 | Table checking/dumping program |
Previous Message | Mario Weilguni | 2002-04-24 14:28:05 | Re: Inefficient handling of LO-restore + Patch |