Re: Unicode mapping scripts cleanup

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

In response to

Responses

Browse pgsql-hackers by date

  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