Re: Update Unicode data to Unicode 16.0.0

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Update Unicode data to Unicode 16.0.0
Date: 2024-11-15 16:09:58
Message-ID: 55434f09-ba2c-4b10-bf45-ab554309f3bb@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12.11.24 10:40, Laurenz Albe wrote:
> On Mon, 2024-11-11 at 14:52 -0500, Joe Conway wrote:
>> On 11/11/24 01:27, Peter Eisentraut wrote:
>>> Here is the patch to update the Unicode data to version 16.0.0.
>>>
>>> Normally, this would have been routine, but a few months ago there was
>>> some debate about how this should be handled. [0]  AFAICT, the consensus
>>> was to go ahead with it, but I just wanted to notify it here to be clear.
>>>
>>> [0]:
>>> https://www.postgresql.org/message-id/flat/d75d2d0d1d2bd45b2c332c47e3e0a67f0640b49c.camel%40j-davis.com
>>
>> I ran a check and found that this patch causes changes in upper casing
>> of some characters.
>
> I want to reiterate what I said in the above thread:
> If that means that indexes on strings using the "builtin" collation
> provider need to be reindexed after an upgrade, I am very much against it.

The practice of regularly updating the Unicode files is older than the
builtin collation provider. It is similar to updating the time zone
files, the encoding conversion files, the snowball files, etc. We need
to move all of these things forward to keep up with the aspects of the
real world that this data reflects. New features are required to live
in that environment. If a new feature were proposed that would then
require us to stop updating any of these files, we would likely not
accept that, or at least need a very deliberate discussion about that
before the feature is introduced. This was not done here at all. If
this new feature has this hidden requirement, then that feature is not
complete yet, and work should probably continue to make that feature
complete. But that can't take progress in other areas hostage.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2024-11-15 16:19:07 Re: POC: make mxidoff 64 bits
Previous Message Peter Eisentraut 2024-11-15 15:42:31 Re: Support LIKE with nondeterministic collations