On ons, 2010-09-22 at 19:25 +0800, Craig Ringer wrote:
> Yep, I tend to think that'd be the right way to go. It'd still be a bit
> of a pain, though, as messages written to stdout/stderr by the
> postmaster should be in the system encoding, but messages written to the
> log files should be in the encoding specified for logs, unless logging
> is being done to syslog, in which case it has to be in the system
> encoding after all...
I think that should not be a problem to implement. Those two go through
different routines anyway.
> And, of course, the postmaster still doesn't know how to log anything it
> might emit before reading postgresql.conf, because it doesn't know what
> encoding to use.
That should also not be a big issue. The postmaster needs the
configuration file to know where to write the log file anyway.
> 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.
I don't think this would make things better or easier. At some point
you're going to have to insert a recode call, and it doesn't matter much
whether the destination argument is a constant or a variable.