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-24 21:45:58 |
Message-ID: | 21564.1024955158@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:
> I was hoping it would be acceptable to leave this function in (as well
> as the one to get the number of config variables), once it was renamed
> to remove the reference to GUC.
> Without it, it is impossible for a user function to return a list of
> config variables without prior knowledge of the config variable names. I
> would still like to have this ability. The only workaround without these
> functions is to parse "SHOW ALL" output which is an awfully ugly
> alternative.
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.
Also, I think Peter was objecting to exposing the name "GUC" at the
SQL function name level. I see no reason to avoid the phrase at the
C level; C code is going to be #including "utils/guc.h" anyway, so...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-24 23:32:25 | Re: More schema support for psql |
Previous Message | Tom Lane | 2002-06-24 20:53:17 | Re: several minor cleanups |