Re: GUC flags

On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote:
> 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.

I want to avoid putting this in pg_settings.

The two options discussed so far are:
- to add an function to return the flags;
- to add the flags to pg_show_all_settings(), but not show it in pg_settings view;

I interpretted Michael's suggested as adding it to pg_get_all_settings(), but
*not* including it in the pg_settings view. Now it seems like I misunderstood,
and Michael wants to add it to the view.

But, even if we only handle the 5 flags we have an immediate use for, it makes
the user-facing view too "wide", just to accommodate this internal use.

If it were in the pg_settings view, I think it ought to have *all* the flags
(not just the flags that help us to retire ./check_guc). That's much too much.

--
Justin