Re: BUG #5661: The character encoding in logfile is confusing. - Mailing list pgsql-hackers

From Dave Page
Subject Re: BUG #5661: The character encoding in logfile is confusing.
Date
Msg-id AANLkTinX6kKqwXZ1G3JwLkZBZQriNYrKQ=f5T_FQ6vGA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5661: The character encoding in logfile is confusing.  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-hackers
On Wed, Sep 22, 2010 at 12:25 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> I don't think that's an OK answer, myself. Mixed encodings with no
> delineation in one file = bug as far as I'm concerned. You can't even rely
> on being able to search the log anymore. You'll only get away with it when
> using languages that mostly stick to the 7-bit ASCII subset, so most text is
> still readable; with most other languages you'll get logs full of what looks
> to the user like garbage.

This issue crops up periodically in the pgAdmin lists as well, as the
mixed encoding sometimes break the log viewer.

> I still wonder if, rather than making this configurable, the right choice is
> to force logging to UTF-8 (with BOM) across the board, right from postmaster
> startup. It's consistent, all messages in all other encodings can be
> converted to UTF-8 for logging, it's platform independent, and text editors
> etc tend to understand and recognise UTF-8 especially with the BOM.

That would be ideal for us.

> Unfortunately, because many unix utilities (grep etc) aren't encoding aware,
> that'll cause problems when people go to search log files. For (eg) "広告掲載"

But not for others!

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: snapshot generation broken
Next
From: Peter Eisentraut
Date:
Subject: Re: snapshot generation broken