Re: GUC flags

On Tue, Jan 25, 2022 at 12:07:51PM -0600, Justin Pryzby wrote:
> On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote:
>> 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.)

EXPLAIN is useful to know which parameter could be part of an explain
query, as that's not an information provided now, even if the category
provides a hint. COMPUTED is also useful for the purpose of postgres
-C in my opinion. I am reserved about the rest in terms of user
experience, but the other ones are useful to automate the checks
check_guc was doing, which is still the main goal of this patch if we
remove this script. And experience has proved lately that people
forget a lot to mark GUCs correctly.

> 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.

Yeah, I meant to add that in the view, as it is already wide. I'd be
fine with a separate SQL function at the end, but putting that in
pg_show_all_settings() without considering pg_settings would not be
consistent. There is the argument that one could miss an update of
system_views.sql if adding more data to pg_show_all_settings(), even
if that's not really going to happen.

> 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.

short_desc and extra_desc count for most of the bloat already, so that
would not change much, but I am fine to discard my point to not make
things worse.
--
Michael