From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Cc: bruce@momjian.us
Cc: tgl@sss.pgh.pa.us
Subject: Re: GUC flags
Date: Tue, 25 Jan 2022 12:07:51 -0600
Message-ID: <20220125180751.GH23027@telsasoft.com> (raw)
In-Reply-To: <d363c358-2c67-92bc-660f-ff82636c155f@enterprisedb.com>
References: <20211209155322.GG17618@telsasoft.com>
<20211229023240.GM24477@telsasoft.com>
<20220105.114757.369416916044334409.horikyota.ntt@gmail.com>
<20220105030648.GE14051@telsasoft.com>
<YdUp118ekFgGiixT@paquier.xyz>
<20220105235517.GR14051@telsasoft.com>
<YdZ7zCymonPV4//X@paquier.xyz>
<20220106053641.GW14051@telsasoft.com>
<20220125010729.GC23027@telsasoft.com>
<d363c358-2c67-92bc-660f-ff82636c155f@enterprisedb.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, peter.eisentraut@enterprisedb.com, michael@paquier.xyz, horikyota.ntt@gmail.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Subject: Re: GUC flags
In-Reply-To: <20220125180751.GH23027@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox