Re: GUC names in messages

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