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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
