Re: GUC flags

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: GUC flags
Date: 2021-12-09 15:53:23
Message-ID: 20211209155322.GG17618@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).

Attachment Content-Type Size
0001-check_guc-fix-absurd-number-of-false-positives.patch text/x-diff 3.9 KB
0002-Expose-GUC-flags-in-pg_settings-retire-.-check_guc.patch text/x-diff 13.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-12-09 15:58:21 Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Previous Message Peter Eisentraut 2021-12-09 15:51:17 Re: Readd use of TAP subtests