Horton

Re: GUC flags

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Date: 2022-01-26T06:29:29Z
Lists: pgsql-hackers 
On Tue, Jan 25, 2022 at 09:44:26PM -0600, Justin Pryzby wrote:
> 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.

My vote would be to have a documented function, with a minimal set of
the flags exposed and documented, with the option to expand that in
the future.  COMPUTED and EXPLAIN are useful, and allow some of the
automated tests to happen.  NOT_IN_SAMPLE and GUC_NO_SHOW_ALL are less 
useful for the user, and are more developer oriented, but are useful
for the tests.  So having these four seem like a good first cut.
--
Michael

Commits

  1. Add TAP test to automate the equivalent of check_guc, take two

  2. Retire src/backend/utils/misc/check_guc

  3. Add TAP test to automate the equivalent of check_guc

  4. Add PostgreSQL::Test::Cluster::config_data()

  5. Introduce pg_settings_get_flags() to find flags associated to a GUC

  6. Revert changes about warnings/errors for placeholders.

  7. Improve the description of various GUCs