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
