On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote: > I have been thinking about this for years and I think the key idea for > this is, implementing "universal encoding". The universal encoding > should have following characteristics to implement N>2 encoding in a > database. > > 1) no loss of round trip encoding conversion > > 2) no mapping table is necessary to convert from/to existing encodings > > Once we implement the universal encoding, other problem such as > "pg_database with multiple encoding problem" can be solved easily.
Isn't this essentially what the MULE internal encoding is? > Currently there's no such an universal encoding in the universe, I > think the only way is, inventing it by ourselves. This sounds like a terrible idea. In the future people are only going to want more advanced text functions, regular expressions, indexing and making encodings that don't exist anywhere else seems like a way to make a lot of work for little benefit. A better idea seems to me is to (if postgres is configured properly) embed the non-round-trippable characters in the custom character part of the unicode character set. In other words, adjust the mappings tables on demand and voila. Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
