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