>> I think so. We must be very careful updating the maps. Adding new >> mapping data would cause less problem, but replacing existing mappings >> will be definitely a big problem for users. > > Note that I'm not actually proposing to change the mappings, I just want > to get the scripts into working order, to put us into a position to > consider changes if necessary. > > That said, I'm not sure what the problem with changes would be. The > data in the databases doesn't change. You just see different data > coming out. It is in the nature of encoding conversion that you don't > get the original data, but an approximation.
I don't buy the argument "user's should accept the behavior change because data inside PostgreSQL does not change". I think we should care about user's application in total. > Then again, I don't have > any knowledge about how to handle such changes. But the fact that the > standards bodies are still making changes indicates that such changes > are to be expected and should be handled. I think this is similar to > time zone changes, and also similar in different ways to collation changes. The question here is, as far as I know, the encoding mappings are *not* part of the Unicode standard, nor any kind of other standards, then why do we need strictly follow the mapping data with sacrificing application's compatibility. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
