Re: Unicode mapping scripts cleanup - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Unicode mapping scripts cleanup
Date
Msg-id CA+TgmoYrdqMqnmo-d2aukU2P9-pSR7k9oZ_mg9uTDngMKGH7yw@mail.gmail.com
Whole thread Raw
In response to Re: Unicode mapping scripts cleanup  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Unicode mapping scripts cleanup  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
On Tue, Sep 15, 2015 at 9:00 PM, Tatsuo Ishii <ishii@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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: hot_standby_feedback default and docs
Next
From: Teodor Sigaev
Date:
Subject: Re: WIP: Rework access method interface