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-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

In response to

Responses

Browse pgsql-patches by date

  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