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. Sometimes
> it bothers me since I have to analyze server logs and discovered that
> lc_messages is set to pt_BR and to worse things that stup^H^H^H
> application parse some error messages in portuguese. My solution has
> been a modified version of pgBadger (former was pgfouine) -- that has
> its problems: (i) translations are not as stable as english messages,
> (ii) translations are not always available and it means there is a mix
> of translated and untranslated messages and (iii) it is minor version
> dependent. I'm tired to fight against those problems and started to
> research if there is a good solution for backend.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
