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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Date: 2022-01-05T05:17:11Z
Lists: pgsql-hackers 
On Tue, Jan 04, 2022 at 09:06:48PM -0600, Justin Pryzby wrote:
> I think pg_get_guc_flags() may be best, but I'm interested to hear other
> opinions.

My opinion on this matter is rather close to what you have here with
handling things through one extra attribute.  But I don't see the
point of using an extra function where users would need to do a manual
mapping of the flag bits back to a a text representation of them.  So
I would suggest to just add one text[] to pg_show_all_settings, with
values being the bit names themselves, without the prefix "GUC_", for
the ones we care most about.  Sticking with one column for each one
would require a catversion bump all the time, which could be
cumbersome in the long run.
--
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