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

From Peter Smith
Subject Re: GUC names in messages
Date
Msg-id CAHut+PtqTao+OKRxGcCzUxt9h9d0=TQZZoRjMYe3xe0-O7_hsQ@mail.gmail.com
Whole thread Raw
In response to Re: GUC names in messages  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: GUC names in messages
List pgsql-hackers
On Wed, Nov 8, 2023 at 7:40 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> FWIW, I am halfway through doing regex checking of the PG16 source for
> all GUC names in messages to see what current styles are in use today.
>
> Not sure if those numbers will influence the decision.
>
> I hope I can post my findings today or tomorrow.
>

Here are my findings from the current PG16 source messages.

I used a regex search:
".*GUCNAME

to find how each GUCNAME is used in the messages in *.c files.

The GUC names are taken from the guc_tables.c code, so they are
grouped accordingly below.

~TOTALS:

messages where GUC names are QUOTED:
- bool = 11
- int = 11
- real = 0
- string = 10
- enum = 7
TOTAL = 39

messages where GUC names are NOT QUOTED:
- bool = 14
- int = 60
- real = 0
- string = 59
- enum = 31
TOTAL = 164

~~~

Details are in the attached file. PSA.

I've categorised them as being currently QUOTED, NOT QUOTED, and NONE
(most are not used in any messages).

Notice that NOT QUOTED is the far more common pattern, so my vote
would be just to standardise on making everything this way. I know
there was some concern raised about ambiguous words like "timezone"
and "datestyle" etc but in practice, those are rare. Also, those GUCs
are different in that they are written as camel-case (e.g.
"DateStyle") in the guc_tables.c, so if they were also written
camel-case in the messages that could remove ambiguities with normal
words. YMMV.

Anyway, I will await a verdict about what to do.

======
Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: Moving forward with TDE [PATCH v3]
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade and logical replication