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-16T21:06:51Z
Lists: pgsql-hackers

Attachments

On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote:
> 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).

Fixed regression tests caused by another patches.

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