From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg S <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unicode mapping scripts cleanup |
Date: | 2015-09-16 17:24:59 |
Message-ID: | CA+TgmoYrdqMqnmo-d2aukU2P9-pSR7k9oZ_mg9uTDngMKGH7yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 15, 2015 at 9:00 PM, Tatsuo Ishii <ishii(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2015-09-16 17:44:34 | Re: WIP: Rework access method interface |
Previous Message | Michael Paquier | 2015-09-16 17:12:38 | Re: hot_standby_feedback default and docs |