Re: Inefficient handling of LO-restore + Patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inefficient handling of LO-restore + Patch
Дата
Msg-id 11803.1019658626@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inefficient handling of LO-restore + Patch  (Philip Warner <pjw@rhyme.com.au>)
Ответы Re: Inefficient handling of LO-restore + Patch  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mario Weilguni"
Дата:
Сообщение: Re: Inefficient handling of LO-restore + Patch
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Table checking/dumping program