From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
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 21:44:26 -0600
Message-ID: <20220126034426.GN23027@telsasoft.com> (raw)
In-Reply-To: <YfCb03sRzkgNVwbL@paquier.xyz>
References: <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>
<20220125180751.GH23027@telsasoft.com>
<YfCb03sRzkgNVwbL@paquier.xyz>
On Wed, Jan 26, 2022 at 09:54:43AM +0900, Michael Paquier wrote:
> 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.
It seems like an arbitrary and short-sighted policy to expose a handful of
flags in the view for the purpose of retiring ./check_guc, but not expose other
flags, because we thought we knew that no user could ever want them.
We should either expose all the flags, or should put them into an undocumented
function. Otherwise, how would we document the flags argument ? "Shows some
of the flags" ? An undocumented function avoids this issue.
Should I update the patch to put the function back ?
Should I also make the function expose all of the flags ?
--
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, michael@paquier.xyz, peter.eisentraut@enterprisedb.com, horikyota.ntt@gmail.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Subject: Re: GUC flags
In-Reply-To: <20220126034426.GN23027@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