Re: GUC flags

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: pryzby@telsasoft.com
Cc: michael@paquier.xyz, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org, bruce@momjian.us, tgl@sss.pgh.pa.us
Date: 2022-01-06T05:35:54Z
Lists: pgsql-hackers
At Tue, 4 Jan 2022 21:06:48 -0600, Justin Pryzby <pryzby@telsasoft.com> wrote in 
> On Wed, Jan 05, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 28 Dec 2021 20:32:40 -0600, Justin Pryzby <pryzby@telsasoft.com> wrote in 
> In that case, *all* the flags should be exposed.  There's currently 20, which
> means it may not work well after all - it's already too long, and could get
> longer, and/or overflow the alphabet...

Yeah, if we show all 20 properties, the string is too long as well as
all properties cannot have a sensible abbreviation character..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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