| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: GUC names in messages |
| Date: | 2023-12-14 08:38:40 |
| Message-ID: | 6d66eb1a-290d-4aaa-972a-0a06a1af02af@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11.12.23 00:07, Peter Smith wrote:
> If the rule is changed to quote those MixedCase GUCs then the docs
> will require minor tweaking
>
> CURRENT
> <para>
> In messages containing configuration variable names, do not include quotes
> when the names are visibly not natural English words, such as when they
> have underscores, are all-uppercase or have mixed case. Otherwise, quotes
> must be added. Do include quotes in a message where an arbitrary variable
> name is to be expanded.
> </para>
>
> "are all-uppercase or have mixed case." --> "or are all-uppercase."
After these discussions, I think this rule change was not a good idea.
It effectively enforces these kinds of inconsistencies. For example, if
you ever refactored
"DateStyle is wrong"
to
"%s is wrong"
you'd need to adjust the quotes, and thus user-visible behavior, for
entirely internal reasons. This is not good. And then came the idea to
determine the quoting dynamically, which I think everyone agreed was too
much. So I don't see a way to make this work well.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2023-12-14 08:49:04 | Re: Add code indentation check to cirrus-ci (was Re: Add BF member koel-like indentation checks to SanityCheck CI) |
| Previous Message | Peter Eisentraut | 2023-12-14 08:32:09 | Re: Simplify newNode() |