>> You can google by "encoding "EUC_JP" has no equivalent in "UTF8"" or
>> some such to find such an example. In this case PostgreSQL just throw
>> an error. For frontend/backend encoding conversion this is fine. But
>> what should we do for logs? Apparently we cannot throw an error here.
>>
>> "Unification" is another problem. Some kanji characters of CJK are
>> "unified" in Unicode. The idea of unification is, if kanji A in China,
>> B in Japan, C in Korea looks "similar" unify ABC to D. This is a great
>> space saving:-) The price of this is inablity of
>> round-trip-conversion. You can convert A, B or C to D, but you cannot
>> convert D to A/B/C.
>>
>> BTW, I'm not stick with mule-internal encoding. What we need here is a
>> "super" encoding which could include any existing encodings without
>> information loss. For this purpose, I think we can even invent a new
>> encoding(maybe something like very first prposal of ISO/IEC
>> 10646?). However, using UTF-8 for this purpose seems to be just a
>> disaster to me.
>>
> Ok, maybe the time of real universal encoding has not yet come. Then
> we maybe just should add a new parameter "log_encoding" (UTF-8 by
> default) to postgresql.conf. And to use this encoding consistently
> within logging_collector.
> If this encoding is not available then fall back to 7-bit ASCII.
What do you mean by "not available"?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp