> Peter Eisentraut explained that the translation system can not handle > strings broken by macros, e.g. errmsg("foo" MACRO "bar"), since it doesn't > know statically what the macro resolves to. But I am not familiar with our > translation system myself. But if we allow INT64_FORMAT, LSN_FORMAT should > be allowed. That makes life much easier. We do not need other functions at > all. > > Peter E or somebody familiar with translations can provide more > information.
We don't allow INT64_FORMAT in translatable strings, period. (See commit 6a1cd8b9236d which undid some hacks we had to use to work around the lack of it, by allowing %llu to take its place.) For the same reason, we cannot allow LSN_FORMAT or similar constructions in translatable strings either.
If the solution to ugliness of LSN printing is going to require that we add a "%s" which prints a previously formatted string with LSN_FORMAT, it won't win us anything.
Thanks for the commit. The commit reverted code which uses a char array to print int64. On the same lines, using a character array to print an LSN won't be acceptable. I agree.
Maybe we should update the section "Message-Writing Guidelines" in doc/src/sgml/nls.sgml. I think it's implied by "Do not construct sentences at run-time, like ... " but using a macro is not really constructing sentences run time. Hopefully, some day, we will fix the translation system to handle strings with macros and make it easier to print PG specific objects in strings easily.
As annoyed as I am about our LSN printing, I don't think this patch has the solutions we need.
I think we could at least accept the macros so that they can be used in non-translatable strings i.e. use it with sprints, appendStringInfo variants etc. The macros will also serve to document the string format of LSN. Developers can then copy from the macros rather than copying from "some other" (erroneous) usage in the code.