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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to