From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, bruce(at)momjian(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: GUC flags |
Date: | 2022-01-25 10:47:14 |
Message-ID: | d363c358-2c67-92bc-660f-ff82636c155f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25.01.22 02:07, Justin Pryzby wrote:
> +CREATE TABLE pg_settings_flags AS SELECT name, category,
> + 'NO_SHOW_ALL' =ANY(flags) AS no_show_all,
> + 'NO_RESET_ALL' =ANY(flags) AS no_reset_all,
> + 'NOT_IN_SAMPLE' =ANY(flags) AS not_in_sample,
> + 'EXPLAIN' =ANY(flags) AS guc_explain,
> + 'COMPUTED' =ANY(flags) AS guc_computed
> + FROM pg_show_all_settings();
Does this stuff have any value for users? I'm worried we are exposing a
bunch of stuff that is really just for internal purposes. Like, what
value does showing "not_in_sample" have? On the other hand,
"guc_explain" might be genuinely useful, since that is part of a
user-facing feature. (I don't like the "guc_*" naming though.)
Your patch doesn't contain a documentation change, so I don't know how
and to what extend this is supposed to be presented to users.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-01-25 10:54:29 | Re: PublicationActions - use bit flags. |
Previous Message | Peter Eisentraut | 2022-01-25 10:40:45 | Re: WIN32 pg_import_system_collations |