From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: GUC values - recommended way to declare the C variables? |
Date: | 2022-10-27 02:14:37 |
Message-ID: | 20221027021436.GZ16921@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 27, 2022 at 11:06:56AM +0900, Michael Paquier wrote:
> On Wed, Oct 26, 2022 at 06:31:56PM +1100, Peter Smith wrote:
> > I re-checked all the GUC C vars which your patch flags as
> > GUC_DEFAULT_COMPILE. For some of them, where it was not any trouble, I
> > made the C var assignment use the same preprocessor rules as used by
> > guc_tables. For others (mostly the string ones) I left the GUC C var
> > untouched because the sanity checker function already has a rule not
> > to complain about int GUC C vars which are 0 or string GUC vars which
> > are NULL.
>
> I see. So you have on this thread an independent patch to make the CF
> bot happy, still depend on the patch posted on [1] to bypass the
> changes with variables whose boot values are compilation-dependent.
It seems like you're reviewing the previous version of the patch, rather
than the one attached to the message you responded to (which doesn't
have anything to do with GUC_DEFAULT_COMPILE).
I don't know what you meant by "make the CF bot happy" (?)
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-10-27 02:33:48 | Re: GUC values - recommended way to declare the C variables? |
Previous Message | Masahiko Sawada | 2022-10-27 02:11:15 | Re: [PoC] Improve dead tuple storage for lazy vacuum |