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