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
