Re: GUC values - recommended way to declare the C variables?

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

In response to

Responses

Browse pgsql-hackers by date

  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