From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: show() function |
Date: | 2002-06-25 05:42:14 |
Message-ID: | 5006.1024983734@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-06-25 06:35:55 | Re: Some Solaris notes, and an invitation |
Previous Message | Joe Conway | 2002-06-25 05:29:29 | Re: show() function |