nls and server log

From: Euler Taveira <euler(at)timbira(dot)com(dot)br>
To: pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: nls and server log
Date: 2014-12-24 18:35:50
Message-ID: 549B0786.6030606@timbira.com.br
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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?

--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-12-24 18:53:06 Re: Proposal "VACUUM SCHEMA"
Previous Message Adam Brightwell 2014-12-24 17:48:07 Re: Additional role attributes && superuser review