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

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Justin Pryzby <pryzby(at)telsasoft(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 08:00:26
Message-ID: CAHut+PtbJGK9_WS-0+EfO63pPWrPzATixWxdvfL-Zj6A3T1XyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 27, 2022 at 1:33 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
>...
>
> Anyway, per my previous comments in my last message of this thread as
> of https://www.postgresql.org/message-id/Y1nnwFTrnL3ItleP@paquier.xyz,
> I don't see a need for DYNAMIC_DEFAULT from the other thread, nor do I
> see a need to a style like that:
> +/* GUC variable */
> +bool update_process_title =
> +#ifdef WIN32
> + false;
> +#else
> + true;
> +#endif
>
> I think that it would be cleaner to use the same approach as
> checking_after_flush and similar GUCs with a centralized definition,
> rather than spreading such style in two places for each GUC that this
> patch touches (aka its declaration and its default value in
> guc_tables.c). In any case, the patch of this thread still needs some
> adjustments IMO.

PSA patch v6.

The GUC defaults of guc_tables.c, and the modified GUC C var
declarations now share the same common #define'd value (instead of
cut/paste preprocessor code).

Per Michael's suggestion [1] to use centralized definitions.

------
[1] https://www.postgresql.org/message-id/Y1nuDNZDncx7%2BA1j%40paquier.xyz

Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment Content-Type Size
v6-0001-GUC-C-variable-sanity-check.patch application/octet-stream 14.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-10-27 08:04:32 Re: Documentation for building with meson
Previous Message Michael Paquier 2022-10-27 07:23:53 Re: Simplifying our Trap/Assert infrastructure