Horton

Re: GUC flags

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@lists.postgresql.org, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-12-09T15:53:23Z
Lists: pgsql-hackers

Attachments

On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote:
> On Wed, Dec 08, 2021 at 01:23:51PM +0100, Peter Eisentraut wrote:
> > I wasn't really aware of this script either.  But I think it's a good idea
> > to have it.  But only if it's run automatically as part of a test suite run.
> 
> Okay.  If we do that, I am wondering whether it would be better to
> rewrite this script in perl then, so as there is no need to worry
> about the compatibility of grep.  And also, it would make sense to
> return a non-zero exit code if an incompatibility is found for the
> automation part.

One option is to expose the GUC flags in pg_settings, so this can all be done
in SQL regression tests.

Maybe the flags should be text strings, so it's a nicer user-facing interface.
But then the field would be pretty wide, even though we're only adding it for
regression tests.  The only other alternative I can think of is to make a
sql-callable function like pg_get_guc_flags(text guc).

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