Re: show() function
От | Tom Lane |
---|---|
Тема | Re: show() function |
Дата | |
Msg-id | 5006.1024983734@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: show() function (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: show() function
|
Список | pgsql-patches |
Joe Conway <mail@joeconway.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
В списке pgsql-patches по дате отправления: