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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GUC values - recommended way to declare the C variables?
Date: 2022-10-14 04:07:02
Message-ID: 1119172.1665720422@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Thu, Oct 13, 2022 at 11:14:57PM -0400, Tom Lane wrote:
>> For strings, maybe the rule could be "the
>> old value must be NULL or strcmp-equal to the boot_val".

> pg_strcasecmp()'d would be more flexible here?

Don't see the point for that. The case we're talking about is
where the variable is declared like

char *my_guc_variable = "foo_bar";

where the initialization value is going to be a compile-time
constant. I don't see why we'd need to allow any difference
between that constant and the one used in guc_tables.c.

On the other hand, we could insist that string values be strcmp-equal with
no allowance for NULL. But that probably results in duplicate copies of
the string constant, and I'm not sure it buys anything in most places.
Allowing NULL doesn't seem like it creates any extra hazard for early
references, because they'd just crash if they try to use the value
while it's still NULL.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-10-14 04:07:27 Re: Fix error message for MERGE foreign tables
Previous Message Michael Paquier 2022-10-14 03:56:13 Re: GUC values - recommended way to declare the C variables?