Re: nls and server log
От | Robert Haas |
---|---|
Тема | Re: nls and server log |
Дата | |
Msg-id | CA+TgmoaGt2V+_CSW1HFxjLdVs3pre6gccBX84Dg164iSmCsnpA@mail.gmail.com обсуждение исходный текст |
Ответ на | nls and server log (Euler Taveira <euler@timbira.com.br>) |
Ответы |
Re: nls and server log
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: