Joe Conway <mail@joeconway.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