From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: show() function |
Date: | 2002-06-25 05:29:29 |
Message-ID: | 3D17FFB9.2090204@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I agreed with your prior comments that making SHOW ALL return
> query-style output isn't a complete solution --- we should do that,
> but also the GUC variables should be exposed as a (read-only?) table
> or function returning set to allow query-language manipulations of the
> set. 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?
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
Comments?
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-25 05:42:14 | Re: show() function |
Previous Message | Kurt at iadvance | 2002-06-25 00:08:54 | Re: Some Solaris notes, and an invitation |