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