Robert Haas <robertmh...@gmail.com> writes: > On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira <eu...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers