Re: show() function

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

In response to

Responses

Browse pgsql-patches by date

  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