From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nls and server log |
Date: | 2014-12-29 22:39:07 |
Message-ID: | 54A1D80B.10801@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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, possibly doing 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-12-29 22:48:29 | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Previous Message | Jeff Janes | 2014-12-29 22:29:27 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |