Re: Update Unicode data to Unicode 16.0.0

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Jeremy Schneider <schneider(at)ardentperf(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Update Unicode data to Unicode 16.0.0
Date: 2025-03-21 16:15:05
Message-ID: 224411f3-5f98-4bf5-a831-569b2a30a392@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15.03.25 07:54, Jeremy Schneider wrote:
> in favor of leaving it alone because ICU is there for when I need
> up-to-date unicode versions.
>
> From my perspective, the whole point of the builtin collation was to
> one option that avoids these problems that come with updating both ICU
> and glibc.
>
> So I guess the main point of the builtin provider just that it's faster
> than ICU?

A mistake that some people apparently continue to make in this
discussion is that they assume that the only thing the Unicode tables
drive is the builtin collation provider. This is not true, the Unicode
tables were there long before the builtin collation provider, and they
have other purposes. And we knew at the time the builtin collation
provider was added that it would have certain problems with the Unicode
table updates, and we accepted it with the understanding that this would
not change our procedures. Otherwise, we would likely not have accepted
it in its current form.

Those who are now trying to make the builtin collation provider have
properties that it does not have and was not intended to have when it
was added, they would need to arrange the work to make it have those
properties if they want them, rather than insist that progress in other
areas must stop because they are content with the current state.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-03-21 16:18:02 Re: Fix 035_standby_logical_decoding.pl race conditions
Previous Message Matthias van de Meent 2025-03-21 16:14:12 Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?