Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira <euler@timbira.com.br> wrote:
>> Currently the same message goes to server log and client app.
>> ...
>> I'm thinking to carry both translated and untranslated messages if we
>> ask to. We store the untranslated messages if the new GUC (say
>> server_lc_messages) is set. The cost will be copy to new five variables
>> (message, detail, detail_log, hint, and context) in ErrorData struct
>> that will be used iif server_lc_messages is set. A possible optimization
>> is not to use the new variables if the lc_messages and
>> server_lc_messages does not match. My use case is a server log in
>> english but I'm perfect fine allowing server log in spanish and client
>> messages in french. Is it an acceptable plan? Ideas?
> Seems reasonable to me, I think.
The core problem that we've worried about in previous discussions about
this is what to do about translation failures and encoding conversion
failures. That is, there's been worry that a poor choice of "log locale"
could result in failures that don't occur otherwise; failures that could
be particularly nasty if they result in the inability to log important
conditions, perhaps even prevent reporting them to the client either.
While I don't say that we cannot accept any risk of that sort, I think
we should consider what risks exist and whether they can be minimized
before we plow ahead.
It would also be useful to think about the requests we get from time to
time to ensure that log messages appear in a uniform choice of encoding.
I don't know whether trying to enforce a uniform log message locale
would make that easier or harder.
regards, tom lane
