GUC names in messages

Hi hackers,

While reviewing another patch I noticed how the GUCs are
inconsistently named within the GUC_check_errdetail messages:

======

below, the GUC name is embedded but not quoted:

src/backend/access/transam/xlogprefetcher.c:
GUC_check_errdetail("recovery_prefetch is not supported on platforms
that lack posix_fadvise().");
src/backend/access/transam/xlogrecovery.c:
GUC_check_errdetail("recovery_target_timeline is not a valid
number.");
src/backend/commands/variable.c:
GUC_check_errdetail("effective_io_concurrency must be set to 0 on
platforms that lack posix_fadvise().");
src/backend/commands/variable.c:
GUC_check_errdetail("maintenance_io_concurrency must be set to 0 on
platforms that lack posix_fadvise().");
src/backend/port/sysv_shmem.c:
GUC_check_errdetail("huge_page_size must be 0 on this platform.");
src/backend/port/win32_shmem.c:
GUC_check_errdetail("huge_page_size must be 0 on this platform.");
src/backend/replication/syncrep.c:
GUC_check_errdetail("synchronous_standby_names parser failed");
src/backend/storage/file/fd.c:
GUC_check_errdetail("debug_io_direct is not supported on this
platform.");
src/backend/storage/file/fd.c:
GUC_check_errdetail("debug_io_direct is not supported for WAL because
XLOG_BLCKSZ is too small");
src/backend/storage/file/fd.c:
GUC_check_errdetail("debug_io_direct is not supported for data because
BLCKSZ is too small");
src/backend/tcop/postgres.c:
GUC_check_errdetail("client_connection_check_interval must be set to 0
on this platform.");

~~~

below, the GUC name is embedded and double-quoted:

src/backend/commands/vacuum.c:
GUC_check_errdetail("\"vacuum_buffer_usage_limit\" must be 0 or
between %d kB and %d kB",
src/backend/commands/variable.c:
GUC_check_errdetail("Conflicting \"datestyle\" specifications.");
src/backend/storage/buffer/localbuf.c:
GUC_check_errdetail("\"temp_buffers\" cannot be changed after any
temporary tables have been accessed in the session.");
src/backend/tcop/postgres.c:
GUC_check_errdetail("\"max_stack_depth\" must not exceed %ldkB.",
src/backend/tcop/postgres.c: GUC_check_errdetail("Cannot enable
parameter when \"log_statement_stats\" is true.");
src/backend/tcop/postgres.c: GUC_check_errdetail("Cannot enable
\"log_statement_stats\" when "

~~~

below, the GUC name is substituted but not quoted:

src/backend/access/table/tableamapi.c: GUC_check_errdetail("%s
cannot be empty.",
src/backend/access/table/tableamapi.c: GUC_check_errdetail("%s is
too long (maximum %d characters).",

~~~

I had intended to make a patch to address the inconsistency, but
couldn't decide which of those styles was the preferred one.

Then I worried this could be the tip of the iceberg -- GUC names occur
in many other error messages where they are sometimes quoted and
sometimes not quoted:
e.g. Not quoted -- errhint("You might need to run fewer transactions
at a time or increase max_connections.")));
e.g. Quoted -- errmsg("\"max_wal_size\" must be at least twice
\"wal_segment_size\"")));

Ideally, they should all look the same everywhere, shouldn't they?

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

On Wed, Nov 1, 2023 at 8:02 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
...
>
> I had intended to make a patch to address the inconsistency, but
> couldn't decide which of those styles was the preferred one.
>
> Then I worried this could be the tip of the iceberg -- GUC names occur
> in many other error messages where they are sometimes quoted and
> sometimes not quoted:
> e.g. Not quoted -- errhint("You might need to run fewer transactions
> at a time or increase max_connections.")));
> e.g. Quoted -- errmsg("\"max_wal_size\" must be at least twice
> \"wal_segment_size\"")));
>
> Ideally, they should all look the same everywhere, shouldn't they?
>

One idea to achieve consistency might be to always substitute GUC
names using a macro.

#define GUC_NAME(s) ("\"" s "\"")

ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("%s must be at least twice %s",
GUC_NAME("max_wal_size"),
GUC_NAME("wal_segment_size"))));

Thoughts?

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

> On 1 Nov 2023, at 10:02, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:

> GUC_check_errdetail("effective_io_concurrency must be set to 0 on
> platforms that lack posix_fadvise().");
> src/backend/commands/variable.c:
> GUC_check_errdetail("maintenance_io_concurrency must be set to 0 on
> platforms that lack posix_fadvise().");

These should be substituted to reduce the number of distinct messages that need
to be translated. I wouldn't be surprised if more like these have slipped
through.

> I had intended to make a patch to address the inconsistency, but
> couldn't decide which of those styles was the preferred one.

Given the variety in the codebase I don't think there is a preferred one.

> Then I worried this could be the tip of the iceberg

All good rabbit-holes uncovered during hacking are.. =)

> Ideally, they should all look the same everywhere, shouldn't they?

Having a policy would be good, having one which is known and enforced is even
better (like how we are consistent around error messages based on our Error
Message Style Guide).

--
Daniel Gustafsson

> On 1 Nov 2023, at 10:22, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Wed, Nov 1, 2023 at 8:02 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> ...
>>
>> I had intended to make a patch to address the inconsistency, but
>> couldn't decide which of those styles was the preferred one.
>>
>> Then I worried this could be the tip of the iceberg -- GUC names occur
>> in many other error messages where they are sometimes quoted and
>> sometimes not quoted:
>> e.g. Not quoted -- errhint("You might need to run fewer transactions
>> at a time or increase max_connections.")));
>> e.g. Quoted -- errmsg("\"max_wal_size\" must be at least twice
>> \"wal_segment_size\"")));
>>
>> Ideally, they should all look the same everywhere, shouldn't they?
>>
>
> One idea to achieve consistency might be to always substitute GUC
> names using a macro.
>
> #define GUC_NAME(s) ("\"" s "\"")
>
> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("%s must be at least twice %s",
> GUC_NAME("max_wal_size"),
> GUC_NAME("wal_segment_size"))));

Something like this might make translations harder since the remaining string
leaves little context about the message. We already have that today to some
extent (so it might not be an issue), and it might be doable to automatically
add translator comments, but it's something to consider.

--
Daniel Gustafsson

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 1 Nov 2023, at 10:22, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>> One idea to achieve consistency might be to always substitute GUC
>> names using a macro.
>>
>> #define GUC_NAME(s) ("\"" s "\"")
>>
>> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>> errmsg("%s must be at least twice %s",
>> GUC_NAME("max_wal_size"),
>> GUC_NAME("wal_segment_size"))));

> Something like this might make translations harder since the remaining string
> leaves little context about the message. We already have that today to some
> extent (so it might not be an issue), and it might be doable to automatically
> add translator comments, but it's something to consider.

Our error message style guidelines say not to assemble messages out
of separate parts, because it makes translation difficult. Originally
we applied that rule to GUC names mentioned in messages as well.
Awhile ago the translation team decided that that made for too many
duplicative translations, so they'd be willing to compromise on
substituting GUC names. That's only been changed in a haphazard
fashion though, mostly in cases where there actually were duplicative
messages that could be merged this way. And there's never been any
real clarity about whether to quote GUC names, though certainly we're
more likely to quote anything injected with %s. So that's why we have
a mishmash right now.

I'm not enamored of the GUC_NAME idea suggested above. I don't
think it buys anything, and what it does do is make *every single
one* of our GUC-mentioning messages wrong. I think if we want to
standardize here, we should standardize on something that's
already pretty common in the code base.

Another problem with the idea as depicted above is that it
mistakenly assumes that "..." is the correct quoting method
in all languages. You could make GUC_NAME be a pure no-op
macro and continue to put quoting in the translatable string
where it belongs, but then the macro brings even less value.

regards, tom lane

On 01.11.23 10:25, Tom Lane wrote:
> And there's never been any
> real clarity about whether to quote GUC names, though certainly we're
> more likely to quote anything injected with %s. So that's why we have
> a mishmash right now.

I'm leaning toward not quoting GUC names. The quoting is needed in
places where the value can be arbitrary, to avoid potential confusion.
But the GUC names are well-known, and we wouldn't add confusing GUC
names like "table" or "not found" in the future.

On Wed, 2023-11-01 at 16:12 -0400, Peter Eisentraut wrote:
> On 01.11.23 10:25, Tom Lane wrote:
> > And there's never been any
> > real clarity about whether to quote GUC names, though certainly we're
> > more likely to quote anything injected with %s. So that's why we have
> > a mishmash right now.
>
> I'm leaning toward not quoting GUC names. The quoting is needed in
> places where the value can be arbitrary, to avoid potential confusion.
> But the GUC names are well-known, and we wouldn't add confusing GUC
> names like "table" or "not found" in the future.

I agree for names with underscores in them. But I think that quoting
is necessary for names like "timezone" or "datestyle" that might be
mistaken for normal words. My personal preference is to always quote
GUC names, but I think it is OK not to quote GOCs whose name are
clearly not natural language words.

Yours,
Laurenz Albe

On Thu, Nov 2, 2023 at 1:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> > On 1 Nov 2023, at 10:22, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >> One idea to achieve consistency might be to always substitute GUC
> >> names using a macro.
> >>
> >> #define GUC_NAME(s) ("\"" s "\"")
> >>
> >> ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> >> errmsg("%s must be at least twice %s",
> >> GUC_NAME("max_wal_size"),
> >> GUC_NAME("wal_segment_size"))));
>
> > Something like this might make translations harder since the remaining string
> > leaves little context about the message. We already have that today to some
> > extent (so it might not be an issue), and it might be doable to automatically
> > add translator comments, but it's something to consider.
>
> Our error message style guidelines say not to assemble messages out
> of separate parts, because it makes translation difficult. Originally
> we applied that rule to GUC names mentioned in messages as well.
> Awhile ago the translation team decided that that made for too many
> duplicative translations, so they'd be willing to compromise on
> substituting GUC names. That's only been changed in a haphazard
> fashion though, mostly in cases where there actually were duplicative
> messages that could be merged this way. And there's never been any
> real clarity about whether to quote GUC names, though certainly we're
> more likely to quote anything injected with %s. So that's why we have
> a mishmash right now.
>
> I'm not enamored of the GUC_NAME idea suggested above. I don't
> think it buys anything, and what it does do is make *every single
> one* of our GUC-mentioning messages wrong. I think if we want to
> standardize here, we should standardize on something that's
> already pretty common in the code base.
>

Thanks to everybody for the feedback received so far.

Perhaps as a first step, I can try to quantify the GUC name styles
already in the source code. The numbers might help decide how to
proceed

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

On Wed, Nov 01, 2023 at 09:46:52PM +0100, Laurenz Albe wrote:
> I agree for names with underscores in them. But I think that quoting
> is necessary for names like "timezone" or "datestyle" that might be
> mistaken for normal words. My personal preference is to always quote
> GUC names, but I think it is OK not to quote GOCs whose name are
> clearly not natural language words.

+1, IMHO quoting GUC names makes it abundantly clear that they are special
identifiers. In de4d456, we quoted the role names in a bunch of messages.
We didn't quote the attribute/option names, but those are in all-caps, so
they already stand out nicely.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

On 2023-Nov-01, Nathan Bossart wrote:

> On Wed, Nov 01, 2023 at 09:46:52PM +0100, Laurenz Albe wrote:
> > I agree for names with underscores in them. But I think that quoting
> > is necessary for names like "timezone" or "datestyle" that might be
> > mistaken for normal words. My personal preference is to always quote
> > GUC names, but I think it is OK not to quote GOCs whose name are
> > clearly not natural language words.
>
> +1, IMHO quoting GUC names makes it abundantly clear that they are special
> identifiers. In de4d456, we quoted the role names in a bunch of messages.
> We didn't quote the attribute/option names, but those are in all-caps, so
> they already stand out nicely.

I like this, and I propose we codify it in the message style guide. How
about this? We can start looking at code changes to make once we decide
we agree with this.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La verdad no siempre es bonita, pero el hambre de ella sí"

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2023-Nov-01, Nathan Bossart wrote:
>> +1, IMHO quoting GUC names makes it abundantly clear that they are special
>> identifiers. In de4d456, we quoted the role names in a bunch of messages.
>> We didn't quote the attribute/option names, but those are in all-caps, so
>> they already stand out nicely.

> I like this, and I propose we codify it in the message style guide. How
> about this? We can start looking at code changes to make once we decide
> we agree with this.

WFM.

regards, tom lane

On Tue, Nov 07, 2023 at 10:33:03AM +0100, Alvaro Herrera wrote:
> On 2023-Nov-01, Nathan Bossart wrote:
>> +1, IMHO quoting GUC names makes it abundantly clear that they are special
>> identifiers. In de4d456, we quoted the role names in a bunch of messages.
>> We didn't quote the attribute/option names, but those are in all-caps, so
>> they already stand out nicely.
>
> I like this, and I propose we codify it in the message style guide. How
> about this? We can start looking at code changes to make once we decide
> we agree with this.

> + <para>
> + In messages containing configuration variable names, quotes are
> + not necessary when the names are visibly not English natural words, such
> + as when they have underscores or are all-uppercase. Otherwise, quotes
> + must be added. Do include double-quotes in a message where an arbitrary
> + variable name is to be expanded.
> + </para>

І'd vote for quoting all GUC names, if for no other reason than "visibly
not English natural words" feels a bit open to interpretation. But this
seems like it's on the right track, so I won't argue too strongly if I'm
the only holdout.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

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.

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

On Wed, Nov 8, 2023 at 7:40 AM Peter Smith <smithpb2250(at)gmail(dot)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

On Thu, Nov 2, 2023 at 1:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
...
> Our error message style guidelines say not to assemble messages out
> of separate parts, because it makes translation difficult. Originally
> we applied that rule to GUC names mentioned in messages as well.
> Awhile ago the translation team decided that that made for too many
> duplicative translations, so they'd be willing to compromise on
> substituting GUC names. That's only been changed in a haphazard
> fashion though, mostly in cases where there actually were duplicative
> messages that could be merged this way. And there's never been any
> real clarity about whether to quote GUC names, though certainly we're
> more likely to quote anything injected with %s. So that's why we have
> a mishmash right now.

Right. While looking at all the messages I observed a number of them
having almost the same (but not quite the same) wording:

For example,

errhint("Consider increasing the configuration parameter \"max_wal_size\".")));
errhint("You might need to increase %s.", "max_locks_per_transaction")));
errhint("You might need to increase %s.", "max_pred_locks_per_transaction")));
errmsg("could not find free replication state, increase
max_replication_slots")));
hint ? errhint("You might need to increase %s.", "max_slot_wal_keep_size") : 0);
errhint("You may need to increase max_worker_processes.")));
errhint("Consider increasing configuration parameter
\"max_worker_processes\".")));
errhint("Consider increasing the configuration parameter
\"max_worker_processes\".")));
errhint("You might need to increase %s.", "max_worker_processes")));
errhint("You may need to increase max_worker_processes.")));
errhint("You might need to increase %s.", "max_logical_replication_workers")));

~

The most common pattern there is "You might need to increase %s.".

Here is a patch to modify those other similar variations so they share
that common wording.

PSA.

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

At Thu, 9 Nov 2023 12:55:44 +1100, Peter Smith <smithpb2250(at)gmail(dot)com> wrote in
> The most common pattern there is "You might need to increase %s.".
..
> Here is a patch to modify those other similar variations so they share
> that common wording.
>
> PSA.

I'm uncertain whether the phrases "Consider doing something" and "You
might need to do something" are precisely interchangeable. However,
(for me..) it appears that either phrase could be applied for all
messages that the patch touches.

In short, I'm fine with the patch.

By the way, I was left scratching my head after seeing the following
message.

> ereport(PANIC,
> (errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
> - errmsg("could not find free replication state, increase max_replication_slots")));

Being told to increase max_replication_slots in a PANIC
message feels somewhat off to me. Just looking at the message, it
seems unconvincing to increase "slots" because there is a lack of
"state". So, I poked around in the code and found the following
comment:

> ReplicationOriginShmemSize(void)
> {
> ...
> /*
> * XXX: max_replication_slots is arguably the wrong thing to use, as here
> * we keep the replay state of *remote* transactions. But for now it seems
> * sufficient to reuse it, rather than introduce a separate GUC.
> */

I haven't read the related code, but if my understanding based on this
comment is correct, wouldn't it mean that a lack of storage space for
the state at the location outputting the message indicates a bug in
the program, not a user configuration error? In other words, isn't
this message something that at least shouldn't be a user-facing
message, and might it be more appropriate to use an Assert instead?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On 2023-Nov-09, Peter Smith wrote:

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

Well, I think camel-casing is also a sufficient differentiator for these
identifiers not being English words. We'd need to ensure they're always
written that way, when not quoted. However, in cases where arbitrary
values are expanded, I don't know that they would be expanded that way,
so I would still go for quoting in that case.

There's also a few that are not camel-cased nor have any underscores --
looking at postgresql.conf.sample, we have "port", "bonjour", "ssl",
"fsync", "geqo", "jit", "autovacuum", "xmlbinary", "xmloption". (We also
have "include", but I doubt that's ever used in an error message). But
actually, there's more: every reloption is a candidate, and there we
have "fillfactor", "autosummarize", "fastupdate", "buffering". So if we
want to make generic advice on how to deal with option names in error
messages, I think the wording on conditional quoting I proposed should
go in (adding CamelCase as a reason not to quote), and then we can fix
the code to match. Looking at your list, I think the changes to make
are not too numerous.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Nadie está tan esclavizado como el que se cree libre no siéndolo" (Goethe)

On Thu, Nov 9, 2023 at 10:04 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2023-Nov-09, Peter Smith wrote:
>
> > 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.
>
> Well, I think camel-casing is also a sufficient differentiator for these
> identifiers not being English words. We'd need to ensure they're always
> written that way, when not quoted. However, in cases where arbitrary
> values are expanded, I don't know that they would be expanded that way,
> so I would still go for quoting in that case.
>
> There's also a few that are not camel-cased nor have any underscores --
> looking at postgresql.conf.sample, we have "port", "bonjour", "ssl",
> "fsync", "geqo", "jit", "autovacuum", "xmlbinary", "xmloption". (We also
> have "include", but I doubt that's ever used in an error message). But
> actually, there's more: every reloption is a candidate, and there we
> have "fillfactor", "autosummarize", "fastupdate", "buffering". So if we
> want to make generic advice on how to deal with option names in error
> messages, I think the wording on conditional quoting I proposed should
> go in (adding CamelCase as a reason not to quote), and then we can fix
> the code to match. Looking at your list, I think the changes to make
> are not too numerous.
>

Sorry for my delay in getting back to this thread.

PSA a patch for this work.

There may be some changes I've missed, but hopefully, this is a nudge
in the right direction.

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

On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> There may be some changes I've missed, but hopefully, this is a nudge
> in the right direction.

Thanks for spending some time on that.

<para>
+ In messages containing configuration variable names, do not include quotes
+ when the names are visibly not English natural words, such as when they
+ have underscores or 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>

That seems to describe clearly the consensus reached on the thread
(quotes for GUCs that are single terms, no quotes for names that are
obviously parameters).

In terms of messages that have predictible names, 0002 moves in the
needle in the right direction. There seem to be more:
src/backend/postmaster/bgworker.c: errhint("Consider increasing the
configuration parameter \"max_worker_processes\".")));
contrib/pg_prewarm/autoprewarm.c: errhint("Consider increasing
configuration parameter \"max_worker_processes\".")));

Things like parse_and_validate_value() and set_config_option_ext()
include log strings about GUC and these use quotes. Could these areas
be made smarter with a routine to check if quotes are applied
automatically when we have a "simple" GUC name, aka I guess made of
only lower-case characters? This could be done with a islower() on
the string name, for instance.
--
Michael

On 2023-Nov-24, Michael Paquier wrote:

> On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > There may be some changes I've missed, but hopefully, this is a nudge
> > in the right direction.
>
> Thanks for spending some time on that.

+1

> <para>
> + In messages containing configuration variable names, do not include quotes
> + when the names are visibly not English natural words, such as when they
> + have underscores or 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>
>
> That seems to describe clearly the consensus reached on the thread
> (quotes for GUCs that are single terms, no quotes for names that are
> obviously parameters).

Yeah, this is pretty much the patch I proposed earlier.

> In terms of messages that have predictible names, 0002 moves in the
> needle in the right direction. There seem to be more:
> src/backend/postmaster/bgworker.c: errhint("Consider increasing the
> configuration parameter \"max_worker_processes\".")));
> contrib/pg_prewarm/autoprewarm.c: errhint("Consider increasing
> configuration parameter \"max_worker_processes\".")));

Yeah. Also, these could be changed to have the GUC name outside the
message proper, which would reduce the total number of messages. (But
care must be given to the word "the" there.)

> Things like parse_and_validate_value() and set_config_option_ext()
> include log strings about GUC and these use quotes. Could these areas
> be made smarter with a routine to check if quotes are applied
> automatically when we have a "simple" GUC name, aka I guess made of
> only lower-case characters? This could be done with a islower() on
> the string name, for instance.

I think we could leave these improvements for a second round. They
don't need to hold back the improvement we already have.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
https://postgr.es/m/[email protected]

On Fri, Nov 24, 2023 at 10:53:40AM +0100, Alvaro Herrera wrote:
> I think we could leave these improvements for a second round. They
> don't need to hold back the improvement we already have.

Of course, no problem here to do things one step at a time.
--
Michael

On Fri, Nov 24, 2023 at 2:11 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > There may be some changes I've missed, but hopefully, this is a nudge
> > in the right direction.
>
> Thanks for spending some time on that.
>
> <para>
> + In messages containing configuration variable names, do not include quotes
> + when the names are visibly not English natural words, such as when they
> + have underscores or 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>
>
> That seems to describe clearly the consensus reached on the thread
> (quotes for GUCs that are single terms, no quotes for names that are
> obviously parameters).
>
> In terms of messages that have predictible names, 0002 moves in the
> needle in the right direction. There seem to be more:
> src/backend/postmaster/bgworker.c: errhint("Consider increasing the
> configuration parameter \"max_worker_processes\".")));
> contrib/pg_prewarm/autoprewarm.c: errhint("Consider increasing
> configuration parameter \"max_worker_processes\".")));

Done in patch 0002

>
> Things like parse_and_validate_value() and set_config_option_ext()
> include log strings about GUC and these use quotes. Could these areas
> be made smarter with a routine to check if quotes are applied
> automatically when we have a "simple" GUC name, aka I guess made of
> only lower-case characters? This could be done with a islower() on
> the string name, for instance.

See what you think of patch 0003

~~

PSA v2 patches.

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

On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2023-Nov-24, Michael Paquier wrote:
>
> > On Thu, Nov 23, 2023 at 06:27:04PM +1100, Peter Smith wrote:
> > > There may be some changes I've missed, but hopefully, this is a nudge
> > > in the right direction.
> >
> > Thanks for spending some time on that.
>
> +1
>
> > <para>
> > + In messages containing configuration variable names, do not include quotes
> > + when the names are visibly not English natural words, such as when they
> > + have underscores or 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>
> >
> > That seems to describe clearly the consensus reached on the thread
> > (quotes for GUCs that are single terms, no quotes for names that are
> > obviously parameters).
>
> Yeah, this is pretty much the patch I proposed earlier.
>
> > In terms of messages that have predictible names, 0002 moves in the
> > needle in the right direction. There seem to be more:
> > src/backend/postmaster/bgworker.c: errhint("Consider increasing the
> > configuration parameter \"max_worker_processes\".")));
> > contrib/pg_prewarm/autoprewarm.c: errhint("Consider increasing
> > configuration parameter \"max_worker_processes\".")));
>
> Yeah. Also, these could be changed to have the GUC name outside the
> message proper, which would reduce the total number of messages. (But
> care must be given to the word "the" there.)
>

I had posted something similar a few posts back [1], but it just
caused more questions unrelated to GUC name quotes so I abandoned that
temporarily.

So for now, I hope this thread can be only about quotes on GUC names,
otherwise, I thought it may become stuck debating dozens of individual
messages. Certainly later, or in another thread, we can revisit all
messages again to try to identify/extract any "common" ones.

> > Things like parse_and_validate_value() and set_config_option_ext()
> > include log strings about GUC and these use quotes. Could these areas
> > be made smarter with a routine to check if quotes are applied
> > automatically when we have a "simple" GUC name, aka I guess made of
> > only lower-case characters? This could be done with a islower() on
> > the string name, for instance.
>
> I think we could leave these improvements for a second round. They
> don't need to hold back the improvement we already have.
>

I tried something for this already but kept it in a separate patch. See v2-0003

======
[1] https://www.postgresql.org/message-id/CAHut%2BPv8VG7fvXzg5PNeQuUhJG17xwCWNpZSUUkN11ArV%3D%3DCdg%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

On Mon, Nov 27, 2023 at 10:04:35AM +1100, Peter Smith wrote:
> On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> Yeah. Also, these could be changed to have the GUC name outside the
>> message proper, which would reduce the total number of messages. (But
>> care must be given to the word "the" there.)
>
> I had posted something similar a few posts back [1], but it just
> caused more questions unrelated to GUC name quotes so I abandoned that
> temporarily.

Yes, I kind of agree to let that out of the picture for the moment.
It would be good to reduce the translation chunks.

> So for now, I hope this thread can be only about quotes on GUC names,
> otherwise, I thought it may become stuck debating dozens of individual
> messages. Certainly later, or in another thread, we can revisit all
> messages again to try to identify/extract any "common" ones.

-HINT: Perhaps you need a different "datestyle" setting.
+HINT: Perhaps you need a different DateStyle setting.

Is the change for "datestyle" really required? It does not betray the
GUC quoting policy added by 0001.

>> I think we could leave these improvements for a second round. They
>> don't need to hold back the improvement we already have.
>
> I tried something for this already but kept it in a separate patch. See v2-0003

+ if (*p == '_')
+ underscore = true;

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

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> Is there a reason why we don't just use islower() or is that just to
> get something entirely local independent?

islower() and related functions are not to be trusted for this
purpose. They will certainly give locale-dependent results,
and they might give entirely wrong ones if there's any inconsistency
between the database encoding and what libc thinks the locale is.

regards, tom lane

On Mon, Nov 27, 2023 at 12:44 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Nov 27, 2023 at 10:04:35AM +1100, Peter Smith wrote:
> > On Fri, Nov 24, 2023 at 8:53 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> >> Yeah. Also, these could be changed to have the GUC name outside the
> >> message proper, which would reduce the total number of messages. (But
> >> care must be given to the word "the" there.)
> >
> > I had posted something similar a few posts back [1], but it just
> > caused more questions unrelated to GUC name quotes so I abandoned that
> > temporarily.
>
> Yes, I kind of agree to let that out of the picture for the moment.
> It would be good to reduce the translation chunks.
>
> > So for now, I hope this thread can be only about quotes on GUC names,
> > otherwise, I thought it may become stuck debating dozens of individual
> > messages. Certainly later, or in another thread, we can revisit all
> > messages again to try to identify/extract any "common" ones.
>
> -HINT: Perhaps you need a different "datestyle" setting.
> +HINT: Perhaps you need a different DateStyle setting.
>
> Is the change for "datestyle" really required? It does not betray the
> GUC quoting policy added by 0001.
>

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.

I know the code is doing a case-insensitive hashtable lookup but I
suspect some of the string passing still in the code for those
particular GUCs ought to be using the same mixed case string literal
as in the guc_tables.c. Currently, I have seen a few quirks where the
case is inconsistent with the MixedCase docs. It needs some more
investigation to understand the reason. For example,

2023-11-27 11:03:48.565 AEDT [15303] STATEMENT: set intervalstyle=123;
ERROR: invalid value for parameter "intervalstyle": "123"

versus

2023-11-27 11:13:56.018 AEDT [15303] STATEMENT: set datestyle=123;
ERROR: invalid value for parameter DateStyle: "123"

> >> I think we could leave these improvements for a second round. They
> >> don't need to hold back the improvement we already have.
> >
> > I tried something for this already but kept it in a separate patch. See v2-0003
>
> + if (*p == '_')
> + underscore = true;
>
> 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.

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

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

On Mon, 2023-11-27 at 13:41 +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.

I agree with that decision; we should use mixed case for these parameters.

Otherwise we might get complaints that the following query does not return
any results:

SELECT * FROM pg_settings WHERE name = 'timezone';

Yours,
Laurenz Albe

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
>> 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.

> I agree with that decision; we should use mixed case for these parameters.
> Otherwise we might get complaints that the following query does not return
> any results:
> SELECT * FROM pg_settings WHERE name = 'timezone';

Yeah. Like Michael upthread, I've wondered occasionally about changing
these names to all-lower-case. It'd surely be nicer if we'd done it
like that to begin with. But I can't convince myself that the ensuing
user pain would be justified.

regards, tom lane

On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
>>> 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.
>
>> I agree with that decision; we should use mixed case for these parameters.
>> Otherwise we might get complaints that the following query does not return
>> any results:
>> SELECT * FROM pg_settings WHERE name = 'timezone';

(I'm sure that you mean the opposite. This query does not return any
results on HEAD, but it would with "TimeZone".)

> Yeah. Like Michael upthread, I've wondered occasionally about changing
> these names to all-lower-case. It'd surely be nicer if we'd done it
> like that to begin with. But I can't convince myself that the ensuing
> user pain would be justified.

Perhaps not. I'd like to think that a lot of queries on pg_settings
have the wisdom to apply a lower() or upper(), but that's very
unlikely.

- errhint("Perhaps you need a different \"datestyle\" setting.")));
+ errhint("Perhaps you need a different DateStyle setting.")));

Saying that, I'd let this one be in 0002. It causes a log of diff
churn in the tests and quoting it based on Alvaro's suggestion would
still be correct because it's fully lower-case. (Yeah, I'm perhaps
nit-ing here, so feel free to counter-argue if you prefer what the
patch does.)
--
Michael

Here is patch set v3.

Patches 0001 and 0002 are unchanged from v2.

Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
in guc.c, as recently suggested by Michael [1].

~

(Meanwhile, the MixedCase stuff is still an open question, to be
addressed in a later patch version)

======
[1] https://www.postgresql.org/message-id/ZWQVxu8zWIx64V7l%40paquier.xyz

Kind Regards,
Peter Smith.
Fujitsu Australia

On Tue, 2023-11-28 at 07:53 +0900, Michael Paquier wrote:
> On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> > Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
> > > > 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.
> >
> > > I agree with that decision; we should use mixed case for these parameters.
> > > Otherwise we might get complaints that the following query does not return
> > > any results:
> > > SELECT * FROM pg_settings WHERE name = 'timezone';
>
> (I'm sure that you mean the opposite. This query does not return any
> results on HEAD, but it would with "TimeZone".)

No, I meant it just like I said. If all messages suggest that the parameter
is called "timezone", and not "TimeZone" (because we convert the name to lower
case), then it is surprising that the above query does not return results.

It would be better to call the parameter "TimeZone" everywhere.

(It would be best to convert the parameter to lower case, but I am worried
about the compatibility-pain-to-benefit ratio.)

Yours,
Laurenz Albe

On Tue, Nov 28, 2023 at 11:54:33AM +1100, Peter Smith wrote:
> Here is patch set v3.
>
> Patches 0001 and 0002 are unchanged from v2.

After some grepping, I've noticed that 0002 had a mistake with
track_commit_timestamp: some alternate output of modules/commit_ts/
was not updated. meson was able to reproduce the failure as well.

I am not sure regarding what we should do a mixed cases as well, so I
have discarded DateStyle for now, and applied the rest.

Also applied 0001 from Alvaro.

> Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
> in guc.c, as recently suggested by Michael [1].

I cannot think about a better idea as these strings need to be
translated so they need three %s.

+ if (*p == '_')
+ underscore = true;
+ else if ('a' <= *p && *p <= 'z')
+ lowercase = true;

An issue with this code is that it would forget to quote GUCs that use
dots, like the ones from an extension. I don't really see why we
cannot just make the macro return true only if all the characters of a
GUC name is made of lower-case alpha characters?

With an extra indentation applied, I finish with the attached for
0003.
--
Michael

At Thu, 30 Nov 2023 14:59:21 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> > Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
> > in guc.c, as recently suggested by Michael [1].
>
> I cannot think about a better idea as these strings need to be
> translated so they need three %s.

In this patch, the quotation marks cannot be changed from double
quotes.

After a brief review of the use of quotation marks in various
languages, it's observed that French uses guillemets (« »), German
uses lower qutation marks („ “), Spanish uses angular quotation marks
(« ») or alternatively, lower quotetaion marks. Japanese commonly uses
corner brackets (「」), but can also adopt double or single quotation
marks in certain contexts. I took a look at the backend's fr.po file
for a trial, and it indeed seems that guillemets are being used.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Thu, Nov 30, 2023 at 03:29:49PM +0900, Kyotaro Horiguchi wrote:
> In this patch, the quotation marks cannot be changed from double
> quotes.

Indeed, that's a good point. I completely forgot about that.
--
Michael

On Thu, Nov 30, 2023 at 4:59 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Nov 28, 2023 at 11:54:33AM +1100, Peter Smith wrote:
> > Here is patch set v3.
> >
> > Patches 0001 and 0002 are unchanged from v2.
>
> After some grepping, I've noticed that 0002 had a mistake with
> track_commit_timestamp: some alternate output of modules/commit_ts/
> was not updated. meson was able to reproduce the failure as well.
>
> I am not sure regarding what we should do a mixed cases as well, so I
> have discarded DateStyle for now, and applied the rest.
>
> Also applied 0001 from Alvaro.
>

Thanks for pushing those parts.

> > Patch 0003 now uses a "%s%s%s" format specifier with GUC_FORMAT macro
> > in guc.c, as recently suggested by Michael [1].
>
> I cannot think about a better idea as these strings need to be
> translated so they need three %s.
>
> + if (*p == '_')
> + underscore = true;
> + else if ('a' <= *p && *p <= 'z')
> + lowercase = true;
>
> An issue with this code is that it would forget to quote GUCs that use
> dots, like the ones from an extension. I don't really see why we
> cannot just make the macro return true only if all the characters of a
> GUC name is made of lower-case alpha characters?

Not forgotten. I felt the dot separator in such names might be
mistaken for a period in a sentence which is why I left quotes for
those ones. YMMV.

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

> +/*
> + * Return whether the GUC name should be enclosed in double-quotes.
> + *
> + * Quoting is intended for names which could be mistaken for normal English
> + * words. Quotes are only applied to GUC names that are written entirely with
> + * lower-case alphabetical characters.
> + */
> +static bool
> +quotes_needed_for_GUC_name(const char *name)
> +{
> + for (const char *p = name; *p; p++)
> + {
> + if ('a' > *p || *p > 'z')
> + return false;
> + }
> +
> + return true;
> +}

I think you need a function that the name possibly quoted, in a way that
lets the translator handle the quoting:

static char buffer[SOMEMAXLEN];

quotes_needed = ...;

if (quotes_needed)
/* translator: a quoted configuration parameter name */
snprintf(buffer, _("\"%s\""), name);
return buffer
else
/* no translation needed in this case */
return name;

then the calling code just does a single %s that prints the string
returned by this function. (Do note that the function is not reentrant,
like pg_dump's fmtId. Shouldn't be a problem ...)

> @@ -3621,8 +3673,8 @@ set_config_option_ext(const char *name, const char *value,
> {
> if (changeVal && !makeDefault)
> {
> - elog(DEBUG3, "\"%s\": setting ignored because previous source is higher priority",
> - name);
> + elog(DEBUG3, "%s%s%s: setting ignored because previous source is higher priority",
> + GUC_FORMAT(name));

Note that elog() doesn't do translation, and DEBUG doesn't really need
to worry too much about style anyway. I'd leave these as-is.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)

On 30.11.23 06:59, Michael Paquier wrote:
> ereport(elevel,
> (errcode(ERRCODE_UNDEFINED_OBJECT),
> - errmsg("unrecognized configuration parameter \"%s\" in file \"%s\" line %d",
> - item->name,
> + /* translator: %s%s%s is for an optionally quoted GUC name */
> + errmsg("unrecognized configuration parameter %s%s%s in file \"%s\" line %d",
> + GUC_FORMAT(item->name),
> item->filename, item->sourceline)));

I think this is completely over-engineered and wrong. If we start down
this road, then the next person is going to start engineering some rules
by which we should quote file names and other things. Which will lead
to more confusion, not less. The whole point of this quoting thing is
that you do it all the time or not, not dynamically based on what's
inside of it.

The original version of this string (and similar ones) seems the most
correct, simple, and useful one to me.

On Fri, Dec 1, 2023 at 7:38 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 30.11.23 06:59, Michael Paquier wrote:
> > ereport(elevel,
> > (errcode(ERRCODE_UNDEFINED_OBJECT),
> > - errmsg("unrecognized configuration parameter \"%s\" in file \"%s\" line %d",
> > - item->name,
> > + /* translator: %s%s%s is for an optionally quoted GUC name */
> > + errmsg("unrecognized configuration parameter %s%s%s in file \"%s\" line %d",
> > + GUC_FORMAT(item->name),
> > item->filename, item->sourceline)));
>
> I think this is completely over-engineered and wrong. If we start down
> this road, then the next person is going to start engineering some rules
> by which we should quote file names and other things. Which will lead
> to more confusion, not less. The whole point of this quoting thing is
> that you do it all the time or not, not dynamically based on what's
> inside of it.
>
> The original version of this string (and similar ones) seems the most
> correct, simple, and useful one to me.
>

Yeah, trying to manipulate the quoting dynamically seems like it was
an overreach...

Removing that still leaves some other changes needed to "fix" the
messages using MixedCase GUCs.

PSA v4

======
Details:

Patch 0001 -- "datestyle" becomes DateStyle in messages
Rebased this again, which was part of an earlier patch set
- I think any GUC names documented as MixedCase should keep that same
case in messages; this also obeys the guidelines recently pushed [1].
- Some others agreed, expecting the exact GUC name (in the message)
can be found in pg_settings [2].
- OTOH, Michael didn't like the diff churn [3] caused by this patch.

~~~

Patch 0002 -- use mixed case for intervalstyle error message
I found that the GUC name substituted to the error message was coming
from the statement, not from the original name in the guc_tables, so
there was a case mismatch:

BEFORE Patch 0002 (see the lowercase in the error message)
2023-12-08 13:21:32.897 AEDT [32609] STATEMENT: set intervalstyle = 1234;
ERROR: invalid value for parameter "intervalstyle": "1234"
HINT: Available values: postgres, postgres_verbose, sql_standard, iso_8601.

AFTER Patch 0002
2023-12-08 13:38:48.638 AEDT [29684] STATEMENT: set intervalstyle = 1234;
ERROR: invalid value for parameter "IntervalStyle": "1234"
HINT: Available values: postgres, postgres_verbose, sql_standard, iso_8601.

======
[1] GUC quoting guidelines -
https://github.com/postgres/postgres/commit/a243569bf65c5664436e8f63d870b7ee9c014dcb
[2] The case should match pg_settings -
https://www.postgresql.org/message-id/db3e4290ced77111c17e7a2adfb1d660734f5f78.camel%40cybertec.at
[3] Dislike of diff churn -
https://www.postgresql.org/message-id/ZWUd8dYYA9v83KvI%40paquier.xyz

Kind Regards,
Peter Smith.
Fujitsu Australia

On 2023-Dec-08, Peter Smith wrote:

> Patch 0001 -- "datestyle" becomes DateStyle in messages
> Rebased this again, which was part of an earlier patch set
> - I think any GUC names documented as MixedCase should keep that same
> case in messages; this also obeys the guidelines recently pushed [1].

I agree.

> Patch 0002 -- use mixed case for intervalstyle error message
> I found that the GUC name substituted to the error message was coming
> from the statement, not from the original name in the guc_tables, so
> there was a case mismatch:

I agree. Let's also add a test that shows this difference (my 0002
here).

I'm annoyed that this saga has transiently created a few untranslated
strings by removing unnecessary quotes but failing to move the variable
names outside the translatable part of the string. I change a few of
those in 0003 -- mostly the ones in strings already touched by commit
8d9978a7176a, but also a few others. Didn't go out of my way to grep
for other possible messages to fix, though. (I feel like this is
missing some "translator:" comments.)

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"We’ve narrowed the problem down to the customer’s pants being in a situation
of vigorous combustion" (Robert Haas, Postgres expert extraordinaire)

On 08.12.23 05:10, Peter Smith wrote:
> Patch 0001 -- "datestyle" becomes DateStyle in messages
> Rebased this again, which was part of an earlier patch set
> - I think any GUC names documented as MixedCase should keep that same
> case in messages; this also obeys the guidelines recently pushed [1].
> - Some others agreed, expecting the exact GUC name (in the message)
> can be found in pg_settings [2].
> - OTOH, Michael didn't like the diff churn [3] caused by this patch.

I'm fine with adjusting the mixed-case stuff, but intuitively, I don't
think removing the quotes in this is an improvement:

- GUC_check_errdetail("Conflicting \"datestyle\" specifications.");
+ GUC_check_errdetail("Conflicting DateStyle specifications.");

On Sat, Dec 9, 2023 at 1:48 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 08.12.23 05:10, Peter Smith wrote:
> > Patch 0001 -- "datestyle" becomes DateStyle in messages
> > Rebased this again, which was part of an earlier patch set
> > - I think any GUC names documented as MixedCase should keep that same
> > case in messages; this also obeys the guidelines recently pushed [1].
> > - Some others agreed, expecting the exact GUC name (in the message)
> > can be found in pg_settings [2].
> > - OTOH, Michael didn't like the diff churn [3] caused by this patch.
>
> I'm fine with adjusting the mixed-case stuff, but intuitively, I don't
> think removing the quotes in this is an improvement:
>
> - GUC_check_errdetail("Conflicting \"datestyle\" specifications.");
> + GUC_check_errdetail("Conflicting DateStyle specifications.");
>

My original intention of this thread was only to document the GUC name
quoting guidelines and then apply those consistently in the code.

I'm happy either way for the MixedCase names to be quoted or not
quoted, whatever is the consensus.

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

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

This v5* looks good to me, except it will need some further
modification if PeterE's suggestion [1] to keep quotes for the
MixedCase GUCs is adopted.

======
[1] https://www.postgresql.org/message-id/9e7802b2-2cf2-4c2d-b680-b2ccb9db1d2f%40eisentraut.org

Kind Regards,
Peter Smith.
Futjisu Australia.

On Mon, Dec 11, 2023 at 10:14:11AM +1100, Peter Smith wrote:
> This v5* looks good to me, except it will need some further
> modification if PeterE's suggestion [1] to keep quotes for the
> MixedCase GUCs is adopted.

- errdetail("The database cluster was initialized with CATALOG_VERSION_NO %d,"
- " but the server was compiled with CATALOG_VERSION_NO %d.",
- ControlFile->catalog_version_no, CATALOG_VERSION_NO),
+ /*- translator: %s is a variable name and %d is its value */
+ errdetail("The database cluster was initialized with %s %d,"
+ " but the server was compiled with %s %d.",
+ "CATALOG_VERSION_NO",

Good point. There are a lot of strings that can be shaved from the
translations here.

src/backend/access/transam/xlog.c: errdetail("The database cluster was initialized with PG_CONTROL_VERSION %d (0x%08x),"
src/backend/access/transam/xlog.c: errdetail("The database cluster was initialized with PG_CONTROL_VERSION %d,"
src/backend/access/transam/xlog.c: errdetail("The database cluster was initialized without USE_FLOAT8_BYVAL"
src/backend/access/transam/xlog.c: errdetail("The database cluster was initialized with USE_FLOAT8_BYVAL"

I think that you should apply the same conversion for these ones.
There is no gain with the 1st and 3rd ones, but the 2nd and 4th one
can be grouped together.

FWIW, if we don't convert MixedCase GUCs to become mixedcase, I don't
think that there is any need to apply quotes to them because they
don't really look like natural English words. That's as far as my
opinion goes, so feel free to ignore me if the consensus is different.
--
Michael

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.

On Thu, Dec 14, 2023 at 09:38:40AM +0100, Peter Eisentraut wrote:
> 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.

So, what are you suggesting? Should the encouraged rule be removed
from the docs? Or do you object to some of the changes done in the
latest patch series v5?

FWIW, I am a bit meh with v5-0001, because I don't see the benefits.
On the contrary v5-0003 is useful, because it reduces a bit the number
of strings to translate. That's always good to take. I don't have a
problem with v5-0002, either, where we'd begin using the name of the
GUC as stored in the static tables rather than the name provided in
the SET query, particularly for the reason that it makes the GUC name
a bit more consistent even when using double-quotes around the
parameter name in the query, where the error messages would not force
a lower-case conversion. The patch would, AFAIU, change HEAD from
that:
=# SET "intervalstylE" to popo;
ERROR: 22023: invalid value for parameter "intervalstylE": "popo"
To that:
=# SET "intervalstylE" to popo;
ERROR: 22023: invalid value for parameter "IntervalStyle": "popo"

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

Yeah, with the quotes being language-dependent, any idea I can think
of is as good as unreliable and dead.
--
Michael

Hi,

This thread seems to be a bit stuck, so I thought I would try to
summarize my understanding to hopefully get it moving again...

The original intent of the thread was just to introduce some
guidelines for quoting or not quoting GUC names in messages because
previously it seemed quite ad-hoc. Along the way, there was some scope
creep. IIUC, now there are 3 main topics in this thread:

1. GUC name quoting
2. GUC name case
3. Using common messages

======

#1. GUC name quoting.

Some basic guidelines were decided and a patch is already pushed [1].

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

AFAIK there is nothing controversial there, although maybe the
guideline for 'mixed case' needs revisiting depending on objections
about point #2.

~~~

#2. GUC name case.

GUC names defined in guc_tables.c are either lowercase (xxxx),
lowercase with underscores (xxxx_yyyy) or mixed case (XxxxYyyy).

There are only a few examples of mixed case. They are a bit
problematic, but IIUC they are not going to change away so we need to
deal with them:
- TimeZone
- DateStyle
- IntervalStyle

It was proposed (e.g. [2]) that it would be better/intuitive if the
GUC name of the error message would be the same case as in the
guc_table.c. In other words, other words you should be able to find
the same name from the message in pg_settings.

So mesages with "datestyle" should become DateStyle because:
SELECT * FROM pg_settings WHERE name = 'DateStyle'; ==> found
SELECT * FROM pg_settings WHERE name = 'datestlye'; ==> not found

That latest v5 patches make those adjustments
- Patch v5-0001 fixes case for DateStyle. Yeah, there is some diff
churn because there are a lot of DateStyle tests, but IMO that's too
bad.
- Patch v5-0002 fixed case for IntervalStyle.

~~~

#3. Using common messages

Any message with a non-translatable component to them (e.g. the GUC
name) can be restructured in a way so there is a common translatable
errmsg part with the non-translatable parameters substituted.

e.g.
- GUC_check_errdetail("The only allowed value is \"immediate\".");
+ GUC_check_errdetail("The only allowed value is \"%s\".", "immediate");

AFAIK think there is no disagreement that this is a good idea,
although IMO it deserved to be in a separate thread.

I think there will be many messages that qualify to be modified, and
probably there will be some discussion about whether certain common
messages that can be merged -- (e.g. Is "You might need to increase
%s." same as "Consider increasing %s." or not?).

Anyway, this part is a WIP. Currently, patch v5-0003 makes a start for
this task.

//////

I think patches v5-0002, v5-0003 are uncontroversial.

So the sticking point seems to be the MixedCase GUC (e.g. patch
v5-0001). I agree, that the churn is not ideal (it's only because
there are lots of DateStyle messages in test output), but OTOH that's
just what happens if a rule is applied when previously there were no
rules.

Also, PeterE wrote [4]

> On Thu, Dec 14, 2023 at 09:38:40AM +0100, Peter Eisentraut wrote:
> > 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.
>

I didn't understand the problem. By the current guidelines the mixed
case GUC won't quoted in the message (see patch v5-0001)

So whether it is:
errmsg("DateStyle is wrong"), OR
errmsg("%s is wrong", "DateStyle")

where is the "you'd need to adjust the quotes" problem there?

======
[1] GUC quoting guidelines --
https://www.postgresql.org/docs/devel/error-style-guide.html
[2] Case in messages should be same as pg_settings --
https://www.postgresql.org/message-id/db3e4290ced77111c17e7a2adfb1d660734f5f78.camel%40cybertec.at
[3] v5 patches --
https://www.postgresql.org/message-id/202312081255.wlsfmhe2sri7%40alvherre.pgsql
[4] PeterE concerna about DateStyle --
https://www.postgresql.org/message-id/6d66eb1a-290d-4aaa-972a-0a06a1af02af%40eisentraut.org

Kind Regards,
Peter Smith.
Fujitsu Australia

On 21.12.23 07:24, Peter Smith wrote:
> #1. GUC name quoting.
>
> Some basic guidelines were decided and a patch is already pushed [1].
>
> <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>
>
> AFAIK there is nothing controversial there, although maybe the
> guideline for 'mixed case' needs revisiting depending on objections
> about point #2.

Now that I read this again, I think this is wrong.

We should decide the quoting for a category, not the actual content.
Like, quote all file names; do not quote keywords.

This led to the attempted patch to decide the quoting of GUC parameter
names dynamically based on the actual content, which no one really
liked. But then, to preserve consistency, we also need to be uniform in
quoting GUC parameter names where the name is hardcoded.

On Fri, Dec 22, 2023 at 12:24 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 21.12.23 07:24, Peter Smith wrote:
> > #1. GUC name quoting.
> >
> > Some basic guidelines were decided and a patch is already pushed [1].
> >
> > <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>
> >
> > AFAIK there is nothing controversial there, although maybe the
> > guideline for 'mixed case' needs revisiting depending on objections
> > about point #2.
>
> Now that I read this again, I think this is wrong.
>
> We should decide the quoting for a category, not the actual content.
> Like, quote all file names; do not quote keywords.
>
> This led to the attempted patch to decide the quoting of GUC parameter
> names dynamically based on the actual content, which no one really
> liked. But then, to preserve consistency, we also need to be uniform in
> quoting GUC parameter names where the name is hardcoded.
>

I agree. By attempting to define when to and when not to use quotes it
has become overcomplicated.

Earlier in the thread, I counted how quotes were used in the existing
messages [5]; there were ~39 quoted and 164 not quoted. Based on that
we chose to stay with the majority, and leave all the unquoted ones so
only adding quotes "when necessary". In hindsight, that was probably
the wrong choice because it opened a can of worms about what "when
necessary" even means (e.g. what about underscores, mixed case etc).

Certainly one simple rule "just quote everything" is easiest to follow.

~~~

OPTION#1. DO quote hardcoded GUC names everywhere
- pro: consistent with the dynamic names, which are always quoted
- pro: no risk of mistaking GUC names for normal words in the message
- con: more patch changes than not quoting

Laurenz [2] "My personal preference is to always quote GUC names"
Nathan [3][4] "І'd vote for quoting all GUC names, if for no other
reason than "visibly not English natural words" feels a bit open to
interpretation."
PeterE [6] "... to preserve consistency, we also need to be uniform in
quoting GUC parameter names where the name is hardcoded."

~

OPTION#2. DO NOT quote hardcoded GUC names anywhere
- pro: less patch changes than quoting everything
- con: not consistent with the dynamic names, which are always quoted
- con: risk of mistaking GUC names for normal words in the message

PeterE, originally [1] said "I'm leaning toward not quoting GUC
names", but IIUC changed his opinion in [6].

~~~

Given the above, I've updated the v6 patch set to just *always* quote
GUC names. The docs are also re-written.

======
[1] https://www.postgresql.org/message-id/22998fc0-93c2-48d2-b0f9-361cd5764695%40eisentraut.org
[2] https://www.postgresql.org/message-id/4b83f9888428925e3049e24b60a73f4b94dc2368.camel%40cybertec.at
[3] https://www.postgresql.org/message-id/20231102015239.GA82553%40nathanxps13
[4] https://www.postgresql.org/message-id/20231107145821.GA779199%40nathanxps13
[5] https://www.postgresql.org/message-id/CAHut%2BPtqTao%2BOKRxGcCzUxt9h9d0%3DTQZZoRjMYe3xe0-O7_hsQ%40mail.gmail.com
[6] https://www.postgresql.org/message-id/1704b2cf-2444-484a-a7a4-2ba79f72951d%40eisentraut.org

Kind Regards,
Peter Smith.
Fujitsu Australia

On 04.01.24 07:53, Peter Smith wrote:
>> Now that I read this again, I think this is wrong.
>>
>> We should decide the quoting for a category, not the actual content.
>> Like, quote all file names; do not quote keywords.
>>
>> This led to the attempted patch to decide the quoting of GUC parameter
>> names dynamically based on the actual content, which no one really
>> liked. But then, to preserve consistency, we also need to be uniform in
>> quoting GUC parameter names where the name is hardcoded.
>>
>
> I agree. By attempting to define when to and when not to use quotes it
> has become overcomplicated.
>
> Earlier in the thread, I counted how quotes were used in the existing
> messages [5]; there were ~39 quoted and 164 not quoted. Based on that
> we chose to stay with the majority, and leave all the unquoted ones so
> only adding quotes "when necessary". In hindsight, that was probably
> the wrong choice because it opened a can of worms about what "when
> necessary" even means (e.g. what about underscores, mixed case etc).
>
> Certainly one simple rule "just quote everything" is easiest to follow.

I've been going through the translation updates for PG17 these days and
was led back around to this issue. It seems we left it in an
intermediate state that no one was really happy with and which is
arguably as inconsistent or more so than before.

I think we should accept your two patches

v6-0001-GUC-names-docs.patch
v6-0002-GUC-names-add-quotes.patch

which effectively everyone was in favor of and which seem to be the most
robust and sustainable solution.

(The remaining three patches from the v6 set would be PG18 material at
this point.)

On 2024-May-16, Peter Eisentraut wrote:

> I think we should accept your two patches
>
> v6-0001-GUC-names-docs.patch
> v6-0002-GUC-names-add-quotes.patch
>
> which effectively everyone was in favor of and which seem to be the most
> robust and sustainable solution.

I think we should also take patch 0005 in pg17, which reduces the number
of strings to translate.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"XML!" Exclaimed C++. "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.
https://burningbird.net/the-parable-of-the-languages/

> On 16 May 2024, at 13:35, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:

> I think we should accept your two patches

I agree with this.

> v6-0001-GUC-names-docs.patch

+1

> v6-0002-GUC-names-add-quotes.patch

- errmsg("WAL generated with full_page_writes=off was replayed "
+ errmsg("WAL generated with \"full_page_writes=off\" was replayed "

I'm not a fan of this syntax, but I at the same time can't offer a better idea
so this isn't an objection but a hope that it can be made even better during
the v18 cycle.

--
Daniel Gustafsson

> On 16 May 2024, at 13:56, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

> I think we should also take patch 0005 in pg17, which reduces the number
> of strings to translate.

Agreed, lessening the burden on translators is always a good idea.

--
Daniel Gustafsson

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 16 May 2024, at 13:35, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> - errmsg("WAL generated with full_page_writes=off was replayed "
>> + errmsg("WAL generated with \"full_page_writes=off\" was replayed "

> I'm not a fan of this syntax, but I at the same time can't offer a better idea
> so this isn't an objection but a hope that it can be made even better during
> the v18 cycle.

Yeah ... formally correct would be something like

errmsg("WAL generated with \"full_page_writes\"=\"off\" was replayed "

but that's a bit much for my taste.

regards, tom lane

On Thu, May 16, 2024 at 9:35 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 04.01.24 07:53, Peter Smith wrote:
> >> Now that I read this again, I think this is wrong.
> >>
> >> We should decide the quoting for a category, not the actual content.
> >> Like, quote all file names; do not quote keywords.
> >>
> >> This led to the attempted patch to decide the quoting of GUC parameter
> >> names dynamically based on the actual content, which no one really
> >> liked. But then, to preserve consistency, we also need to be uniform in
> >> quoting GUC parameter names where the name is hardcoded.
> >>
> >
> > I agree. By attempting to define when to and when not to use quotes it
> > has become overcomplicated.
> >
> > Earlier in the thread, I counted how quotes were used in the existing
> > messages [5]; there were ~39 quoted and 164 not quoted. Based on that
> > we chose to stay with the majority, and leave all the unquoted ones so
> > only adding quotes "when necessary". In hindsight, that was probably
> > the wrong choice because it opened a can of worms about what "when
> > necessary" even means (e.g. what about underscores, mixed case etc).
> >
> > Certainly one simple rule "just quote everything" is easiest to follow.
>
> I've been going through the translation updates for PG17 these days and
> was led back around to this issue. It seems we left it in an
> intermediate state that no one was really happy with and which is
> arguably as inconsistent or more so than before.
>
> I think we should accept your two patches
>
> v6-0001-GUC-names-docs.patch
> v6-0002-GUC-names-add-quotes.patch
>
> which effectively everyone was in favor of and which seem to be the most
> robust and sustainable solution.
>
> (The remaining three patches from the v6 set would be PG18 material at
> this point.)

Thanks very much for taking an interest in resurrecting this thread.

It was always my intention to come back to this when the dust had
settled on PG17. But it would be even better if the docs for the rule
"just quote everything", and anything else you deem acceptable, can be
pushed sooner.

Of course, there will still be plenty more to do for PG18, including
locating examples in newly pushed code for messages that have slipped
through the cracks during the last few months using different formats,
and other improvements, but those tasks should become easier if we can
get some of these v6 patches out of the way first.

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

On 17.05.24 05:31, Peter Smith wrote:
>> I think we should accept your two patches
>>
>> v6-0001-GUC-names-docs.patch
>> v6-0002-GUC-names-add-quotes.patch
>>
>> which effectively everyone was in favor of and which seem to be the most
>> robust and sustainable solution.
>>
>> (The remaining three patches from the v6 set would be PG18 material at
>> this point.)
> Thanks very much for taking an interest in resurrecting this thread.
>
> It was always my intention to come back to this when the dust had
> settled on PG17. But it would be even better if the docs for the rule
> "just quote everything", and anything else you deem acceptable, can be
> pushed sooner.
>
> Of course, there will still be plenty more to do for PG18, including
> locating examples in newly pushed code for messages that have slipped
> through the cracks during the last few months using different formats,
> and other improvements, but those tasks should become easier if we can
> get some of these v6 patches out of the way first.

I committed your 0001 and 0002 now, with some small fixes.

There has also been quite a bit of new code, of course, since you posted
your patches, so we'll probably find a few more things that could use
adjustment.

I'd be happy to consider the rest of your patch set after beta1 and/or
for PG18.

On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 17.05.24 05:31, Peter Smith wrote:
> >> I think we should accept your two patches
> >>
> >> v6-0001-GUC-names-docs.patch
> >> v6-0002-GUC-names-add-quotes.patch
> >>
> >> which effectively everyone was in favor of and which seem to be the most
> >> robust and sustainable solution.
> >>
> >> (The remaining three patches from the v6 set would be PG18 material at
> >> this point.)
> > Thanks very much for taking an interest in resurrecting this thread.
> >
> > It was always my intention to come back to this when the dust had
> > settled on PG17. But it would be even better if the docs for the rule
> > "just quote everything", and anything else you deem acceptable, can be
> > pushed sooner.
> >
> > Of course, there will still be plenty more to do for PG18, including
> > locating examples in newly pushed code for messages that have slipped
> > through the cracks during the last few months using different formats,
> > and other improvements, but those tasks should become easier if we can
> > get some of these v6 patches out of the way first.
>
> I committed your 0001 and 0002 now, with some small fixes.
>
> There has also been quite a bit of new code, of course, since you posted
> your patches, so we'll probably find a few more things that could use
> adjustment.
>
> I'd be happy to consider the rest of your patch set after beta1 and/or
> for PG18.
>

Thanks for pushing!

I'll try to dedicate more time to this sometime soon to go through all
the code again to track down those loose ends.

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

On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 17.05.24 05:31, Peter Smith wrote:
> >> I think we should accept your two patches
> >>
> >> v6-0001-GUC-names-docs.patch
> >> v6-0002-GUC-names-add-quotes.patch
> >>
> >> which effectively everyone was in favor of and which seem to be the most
> >> robust and sustainable solution.
> >>
> >> (The remaining three patches from the v6 set would be PG18 material at
> >> this point.)
> > Thanks very much for taking an interest in resurrecting this thread.
> >
> > It was always my intention to come back to this when the dust had
> > settled on PG17. But it would be even better if the docs for the rule
> > "just quote everything", and anything else you deem acceptable, can be
> > pushed sooner.
> >
> > Of course, there will still be plenty more to do for PG18, including
> > locating examples in newly pushed code for messages that have slipped
> > through the cracks during the last few months using different formats,
> > and other improvements, but those tasks should become easier if we can
> > get some of these v6 patches out of the way first.
>
> I committed your 0001 and 0002 now, with some small fixes.
>
> There has also been quite a bit of new code, of course, since you posted
> your patches, so we'll probably find a few more things that could use
> adjustment.
>
> I'd be happy to consider the rest of your patch set after beta1 and/or
> for PG18.

Thanks for pushing some of those v6 patches. Here is the new patch set v7*.

I have used a homegrown script/regex to help identify all the GUC
names that still needed quoting. Many of these occurrences are from
recently pushed code -- i.e. they are more recent than that v6-0002
patch previously pushed [1].

The new GUC quoting patches are separated by different GUC types only
to simplify my processing of them.

v7-0001 = Add quotes for GUCs - bool
v7-0002 = Add quotes for GUCs - int
v7-0003 = Add quotes for GUCs - real
v7-0004 = Add quotes for GUCs - string
v7-0005 = Add quotes for GUCs - enum

The other v7 patches are just carried forward unchanged from v6:

v7-0006 = fix case for IntervalStyle
v7-0007 = fix case for Datestyle
v7-0008 = make common translatable message strings

~~~~

STATUS

Here is the status of these v7* patches, and remaining works to do:

* AFAIK those first 5 ("Add quotes") patches can be pushed ASAP in
PG17. If anybody finds more GUCs still not quoted then those are
probably somehow accidentally missed by me and should be fixed.

* The remaining 3 patches may wait until PG18.

* The patch 0008 ("make common translatable message strings") may be
OK to be pushed as-is. OTOH, this is the tip of another iceberg so I
expect if we look harder there will be many many more candidates to
turn into common messages. There may also be examples where 'similar'
messages can use identical common text, but those will require more
discussion/debate case-by-case

* Another remaining task is to check current usage and improve the
consistency of how some of the GUC values have been quoted. Refer to
mail from Kyotaro-san [2] for examples of this.

======
[1] v6-0001,0002 were already pushed.
https://www.postgresql.org/message-id/55ab714f-86e3-41a3-a1d2-a96a115db8bd%40eisentraut.org

[2] https://www.postgresql.org/message-id/20240520.165613.189183526936651938.horikyota.ntt%40gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

On Tue, May 28, 2024 at 4:16 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
...
>
> The new GUC quoting patches are separated by different GUC types only
> to simplify my processing of them.
>
> v7-0001 = Add quotes for GUCs - bool
> v7-0002 = Add quotes for GUCs - int
> v7-0003 = Add quotes for GUCs - real
> v7-0004 = Add quotes for GUCs - string
> v7-0005 = Add quotes for GUCs - enum
>
> The other v7 patches are just carried forward unchanged from v6:
>
> v7-0006 = fix case for IntervalStyle
> v7-0007 = fix case for Datestyle
> v7-0008 = make common translatable message strings
>
> ~~~~

Hi,

Here is a new patch set v8*, which is the same as v7* but fixes an
error in v7-0008 detected by cfbot.

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

CFBot reported some failures, so I have attached the rebased patch set v9*.

I'm hopeful the majority of these might be pushed to avoid more rebasing...

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

Hi.

The cfbot was reporting my patches needed to be rebased.

Here is the rebased patch set v10*. Everything is the same as before
except now there are only 7 patches instead of 8. The previous v9-0001
("bool") patch no longer exists because those changes are now already
present in HEAD.

I hope these might be pushed soon to avoid further rebasing.

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

On Tue, Sep 03, 2024 at 12:00:19PM +1000, Peter Smith wrote:
> Here is the rebased patch set v10*. Everything is the same as before
> except now there are only 7 patches instead of 8. The previous v9-0001
> ("bool") patch no longer exists because those changes are now already
> present in HEAD.
>
> I hope these might be pushed soon to avoid further rebasing.

0001~0004 could just be merged, they're the same thing, for different
GUC types. The consensus mentioned in 17974ec25946 makes that clear.

0007 is a good thing for translators, indeed.. I'll see about doing
something here, at least.
--
Michael

On Tue, Sep 3, 2024 at 4:35 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Sep 03, 2024 at 12:00:19PM +1000, Peter Smith wrote:
> > Here is the rebased patch set v10*. Everything is the same as before
> > except now there are only 7 patches instead of 8. The previous v9-0001
> > ("bool") patch no longer exists because those changes are now already
> > present in HEAD.
> >
> > I hope these might be pushed soon to avoid further rebasing.
>
> 0001~0004 could just be merged, they're the same thing, for different
> GUC types. The consensus mentioned in 17974ec25946 makes that clear.
>
> 0007 is a good thing for translators, indeed.. I'll see about doing
> something here, at least.
> --
> Michael

Hi Michael, thanks for your interest.

I have merged the patches 0001-0004 as suggested. Please see v11 attachments.

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

On Wed, Sep 04, 2024 at 09:17:15AM +1000, Peter Smith wrote:
> I have merged the patches 0001-0004 as suggested. Please see v11 attachments.

Thanks.

It took me some time to go through the whole tree for more
inconsistencies.

In 0001, search_path was missing quotes in vacuumlo.c and oid2name.c.
Not the most critical tools ever, still fixed these.

CheckRequiredParameterValues() has two "wal_level=minimal". Shouldn't
separate quotes be used for the GUC name and its value to be more
consistent with the rest? There are also two "full_page_writes=off"
in xlog.c. Point mentioned at [1] by Daniel on v6, changed as they
are on HEAD by 17974ec25946.

In 0004, there are a couple of changes where this does not represent a
gain for translators, and it was even made worse. For example
huge_page_size updated for sysv but not WIN32, leading to two
messages. The changes in postgres.c, predicate.c, syncrep.c and
variable.c don't show a gain.

The changes in dfmgr.c should have a translator note, I think, because
it becomes unclear what these messages are about.

By the way, I don't get why we use "/*- translator:" in some places
while we document to use "/* translator:" in the NLS section of the
docs. One pattern is much more used than the other, guess which one.

0001 and 0004 have been applied with these tweaks. I am still not
sure about the changes for DateStyle and IntervalStyle in 0002 and
0003. Perhaps others have an opinion that could drive to a consensus.

[1]: https://www.postgresql.org/message-id/[email protected]
--
Michael

Hello Peter,

[ sorry for the kind of off-topic ]

17.05.2024 14:57, Peter Eisentraut wrote:
> I committed your 0001 and 0002 now, with some small fixes.
>
> There has also been quite a bit of new code, of course, since you posted your patches, so we'll probably find a few
> more things that could use adjustment.
>
> I'd be happy to consider the rest of your patch set after beta1 and/or for PG18.

While translating messages, I've encountered a weird message, updated by
17974ec25:
    printf(_("(in \"wal_sync_method\" preference order, except fdatasync is Linux's default)\n"));

Does "except ..." make sense here or it's just a copy-and-paste from docs?:
        The default is the first method in the above list that is supported
        by the platform, except that <literal>fdatasync</literal> is the default on
        Linux and FreeBSD.

Best regards,
Alexander

On Wed, Sep 4, 2024 at 3:54 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
...
> 0001 and 0004 have been applied with these tweaks. I am still not
> sure about the changes for DateStyle and IntervalStyle in 0002 and
> 0003. Perhaps others have an opinion that could drive to a consensus.
>

Thanks for pushing the patches 0001 and 0004.

I have rebased the two remaining patches. See v12 attached.

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

On Tue, Sep 10, 2024 at 05:11:13PM +1000, Peter Smith wrote:
> I have rebased the two remaining patches. See v12 attached.

I've looked over the patch set again, and applied 0002.

0001 could be more ambitious and more consistent, like:
- The GUC name coming from the table's record is only used for
PGC_ENUM, let's use conf->gen.name across the board so as this counts
for custom GUCs.
- Once we do the first bullet point, parse_and_validate_value() can be
simplified as it does not need its "name" argument anymore.
- Once the second bullet point is simplified, going one way up
reveals more in set_config_with_handle(). I was wondering about
pg_parameter_aclcheck() for a bit until I've noticed
convert_GUC_name_for_parameter_acl() that applies a conversion with
the contents of the catalogs when checking for a parameter ACL,
similar to guc_name_compare().

One limitation is in AlterSystemSetConfigFile() where the parameter
name comes from the command and not a GUC record as the ACL check
happens before the GUC table lookup, but we could live with that.

At the end, I get the attached revised 0001. WDYT?
--
Michael

On Mon, Oct 7, 2024 at 3:22 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Sep 10, 2024 at 05:11:13PM +1000, Peter Smith wrote:
> > I have rebased the two remaining patches. See v12 attached.
>
> I've looked over the patch set again, and applied 0002.
>
> 0001 could be more ambitious and more consistent, like:
> - The GUC name coming from the table's record is only used for
> PGC_ENUM, let's use conf->gen.name across the board so as this counts
> for custom GUCs.
> - Once we do the first bullet point, parse_and_validate_value() can be
> simplified as it does not need its "name" argument anymore.
> - Once the second bullet point is simplified, going one way up
> reveals more in set_config_with_handle(). I was wondering about
> pg_parameter_aclcheck() for a bit until I've noticed
> convert_GUC_name_for_parameter_acl() that applies a conversion with
> the contents of the catalogs when checking for a parameter ACL,
> similar to guc_name_compare().
>
> One limitation is in AlterSystemSetConfigFile() where the parameter
> name comes from the command and not a GUC record as the ACL check
> happens before the GUC table lookup, but we could live with that.
>
> At the end, I get the attached revised 0001. WDYT?

Hi Michael.

Thanks for pushing my other patch.

As for what is left, I had made just the minimal patch to fix the
known "IntervalStyle" problem, but that assumed prior knowledge of
what were the only problem names in the first place. Your way is
better -- to always use the record name where possible.

One thing I thought remains not so good is how
set_config_with_handle(name...) function does
record=find_option(name,...) but then all subsequent names are
supposed to be coming from the record->name. It feels confusing to
have that parameter 'name' still in scope after the find(), e.g., when
you should not be using that anymore. So, I tried to separate this
logic into 2 functions -- set_config_with_handle() and
set_config_with_handle_guts(). There are no name overlaps now, but I
wonder if the fix was overkill. See v14.

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

On Tue, Oct 08, 2024 at 06:57:10PM +1100, Peter Smith wrote:
> As for what is left, I had made just the minimal patch to fix the
> known "IntervalStyle" problem, but that assumed prior knowledge of
> what were the only problem names in the first place. Your way is
> better -- to always use the record name where possible.

Yes, useful for custom GUCs, even if I doubt that many of them mix
character casing these days.

> One thing I thought remains not so good is how
> set_config_with_handle(name...) function does
> record=find_option(name,...) but then all subsequent names are
> supposed to be coming from the record->name. It feels confusing to
> have that parameter 'name' still in scope after the find(), e.g., when
> you should not be using that anymore. So, I tried to separate this
> logic into 2 functions -- set_config_with_handle() and
> set_config_with_handle_guts(). There are no name overlaps now, but I
> wonder if the fix was overkill. See v14.

I was also looking at reducing the scope of the "name" variable in
this path, but that makes IMO the code a bit more confusing with the
existing wrapper set_config_option() and set_config_option_ext(),
while the handle is only used within fmgrs.

Applied the previous patch after looking at it again.
--
Michael

On Wed, Oct 9, 2024 at 8:54 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Applied the previous patch after looking at it again.
> --
> Michael

AFAIK this brings my year-long "GUC names" thread to a conclusion.

Thanks, Michael for helping to get these last couple of patches
pushed, and thanks to everybody else who helped with the earlier ones.

I suspect there are plenty more "common" messages yet to be identified
but that can be a task for another thread.

This one is done.

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