Re: Update Unicode data to Unicode 16.0.0 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Update Unicode data to Unicode 16.0.0
Date
Msg-id 224411f3-5f98-4bf5-a831-569b2a30a392@eisentraut.org
Whole thread Raw
In response to Re: Update Unicode data to Unicode 16.0.0  (Jeremy Schneider <schneider@ardentperf.com>)
Responses Re: Update Unicode data to Unicode 16.0.0
List 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.




pgsql-hackers by date:

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