Joe Conway <mail@joeconway.com> writes:
>> Unless someone's up for the pseudo-table implementation, a contrib
>> function returning set seems reasonable.
> I'm not sure I understand what you mean by a pseudo-table -- would a
> table function wrapped in a system view (pg_settings?) be the same thing
> as a pseudo-table?
I was actually alluding to the possibility of a *writable* table, eg
UPDATE pg_settings SET value = 'true' WHERE name = 'debug_print_query';
as a query-language equivalent of
SET debug_print_query = true;
I believe Oracle already manages some settings this way.
A read-only table is easy enough to make from an SRF, see the pg_stats
family of views for an example. I'm not sure how to get the
updatability part though ... and am happy to leave it for another day.
> Short of that, how's this for a plan:
> 1. New backend scalar function and guc.c/guc.h changes (as submitted
> except the function name):
> current_setting(text setting_name)
> 2. modify "SHOW X" to actually perform the equiv of:
> select current_setting('X')
> 3. modify "SHOW ALL" to return query-style output ala EXPLAIN
> 4. submit contrib/showsettings, with a table function
> current_settings(), which is a renamed version of the previously
> submitted show_all_vars() function
I think the exact SQL function names are still open to debate, but
otherwise seems like a plan.
regards, tom lane
