Re: GUC names in messages

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