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