Re: Update Unicode data to Unicode 16.0.0
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Jeremy Schneider <schneider@ardentperf.com>,
Jeff Davis <pgsql@j-davis.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-21T16:15:05Z
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.
Commits
-
pg_upgrade: Fix memory leak in check_for_unicode_update().
- de48056ec7d2 18.0 landed
-
pg_upgrade check for Unicode-dependent relations.
- b81ffa13e356 18.0 landed
-
Update Unicode data to Unicode 16.0.0
- 82a46cca99fa 18.0 landed