On Thu, Nov 2, 2023 at 1:25 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@yesql.se> writes: > > On 1 Nov 2023, at 10:22, Peter Smith <smithpb2...@gmail.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