> I like Craig's idea of adding the client encoding to the log lines. A
> possible problem with that (I'm not an encoding expert) is that a log
> line like that will contain data about the database server meta-data
> (log time, client encoding, etc) in the database default encoding and
> database data (the logged query and user-supplied values) in the
> client encoding. One option would be to use the client encoding for
> the entire log line, but would that result in legible meta-data in
> every encoding?
I think then we get non-human readable logs. We will need one more tool
to open and convert the log (and omit excessive encoding specification
in each line).
> It appears that the primarly here is that SQL statements and
> user-supplied data are being logged, while the log-file is a text file
> in a fixed encoding.
Yes, and in in my opinion there is nothing unusual about it. XML/HTML
are examples of a text files with fixed encoding that can contain
multi-language strings. UTF-8 is the default encoding for XML. And when
it's not good enough (as Tatsou noticed), you still can switch to another.
> Perhaps another solution would be to add the ability to log certain
> types of information (not the core database server log info, of
> course!) to a database/table so that each record can be stored in its
> own encoding?
> That way the transcoding doesn't have to take place until someone is
> reading the log, you'd know what to transcode the data to (namely the
> client_encoding of the reading session) and there isn't any issue of
> transcoding errors while logging statements.
I don't think it would be the simplest solution of the existing problem.
It can be another branch of evolution, but it doesn't answer the
question - what encoding to use for the core database server log?