On Tue, Sep 15, 2015 at 9:00 PM, Tatsuo Ishii <is...@postgresql.org> wrote:
>>  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.

What if we discovered that one of our mappings was wrong?  Suppose
that there is some encoding where the Unicode mapping for "a" is
inadvertently mapped to the letter "b" in some other character set,
and "b" is mapped to "a".  I imagine that anyone using that encoding
would want this fixed; it's a bug.

Other cases might be less clear.  The cost of changing the mappings
should always be compared against the benefit.  But it might still be
the right thing to do in some cases.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Reply via email to