Re: GUC names in messages[ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: GUC names in messages[
Date
Msg-id ZWQVxu8zWIx64V7l@paquier.xyz
Whole thread Raw
In response to Re: GUC names in messages  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On Mon, Nov 27, 2023 at 01:41:18PM +1100, Peter Smith wrote:
> TBH, I suspect something fishy about these mixed-case GUCs.
>
> In the documentation and in the guc_tables.c they are all described in
> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
> messages should use the same case the documentation, which is why I
> changed all the ones you are referring to.

FWIW, I've been tempted for a few years to propose that we should keep
the parsers as they behave now, but format the name of these
parameters in the code and the docs to just be lower-case all the
time.

>> Is there a reason why we don't just use islower() or is that just to
>> get something entirely local independent?  I am not sure that it needs
>> to be that complicated.  We should just check that all the characters
>> are lower-case and apply quotes.
>
> Thanks for the feedback. Probably I have overcomplicated it. I'll revisit it.

The use of a static variable with a fixed size was itching me a bit as
well..  I was wondering if it would be cleaner to use %s%s%s in the
strings adding a note that these are GUC names that may be optionally
quoted, then hide what gets assigned in a macro with a result rather
similar to LSN_FORMAT_ARGS (GUC_FORMAT?).  The routine checking if
quotes should be applied would only need to return a boolean to tell
what to do, and could be hidden in the macro.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Synchronizing slots from primary to standby
Next
From: Andrei Lepikhov
Date:
Subject: Re: Postgres picks suboptimal index after building of an extended statistics