> Tatsuo Ishii <ishii@xxxxxxxxxxxxxx> writes: >> My idea is using mule-internal encoding for the log file instead of >> UTF-8. There are several advantages: > >> 1) Converion to mule-internal encoding is cheap because no conversion >> table is required. Also no information loss happens in this >> conversion. > >> 2) Mule-internal encoding can be handled by emacs, one of the most >> popular editors in the world. > >> 3) No need to worry about locale. Mule-internal encoding has enough >> information about language. > > Um ... but ... > > (1) nothing whatsoever can read MULE, except emacs and xemacs. > > (2) there is more than one version of MULE (emacs versus xemacs, > not to mention any possible cross-version discrepancies). > > (3) from a log volume standpoint, this could be pretty disastrous. > > I'm not for a write-only solution, which is pretty much what this > would be. I'm not sure how long xemacs will survive (the last stable release of xemacs was released in 2009). Anyway, I'm not too worried about your points, since it's easy to convert back from mule-internal code encoded log files to original encoding mixed log file. No information will be lost. Even converting to UTF-8 should be possible. My point is, once the log file is converted to UTF-8, there's no way to convert back to original encoding log file. Probably we treat mule-internal encoded log files as an internal format, and have a utility which does conversion from mule-internal to UTF-8. -- 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
