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
|
Список | 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 по дате отправления: