Re: nls and server log
От | Jim Nasby |
---|---|
Тема | Re: nls and server log |
Дата | |
Msg-id | 54A1D80B.10801@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: nls and server log (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: nls and server log
|
Список | pgsql-hackers |
On 12/28/14, 2:56 AM, Craig Ringer wrote: > On 12/25/2014 02:35 AM, Euler Taveira wrote: >> 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. > > IMO logging is simply broken for platforms where the postmaster and all > DBs don't share an encoding. We mix different encodings in log messages > and provide no way to separate them out. Nor is there a way to log > different messages to different files. > > It's not just an issue with translations. We mix and mangle encodings of > user-supplied text, like RAISE strings in procs, for example. > > We really need to be treating encoding for logging and for the client > much more separately than we currently do. I think any consideration of > translations for logging should be done with the underlying encoding > issues in mind. Agreed. > My personal opinion is that we should require the server log to be > capable of representing all chars in the encodings used by any DB. Which > in practice means that we always just log in utf-8 if the user wants to > permit DBs with different encodings. An alternative would be one file > per database, always in the encoding of that database. How much of this issue is caused by trying to machine-parse log files? Is a better option to improve that case, possiblydoing something like including a field in each line that tells you the encoding for that entry? -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: