>> 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
