Re: Update Unicode data to Unicode 16.0.0
Jeremy Schneider <schneider@ardentperf.com>
From: Jeremy Schneider <schneider@ardentperf.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Peter Eisentraut
<peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-15T06:54:41Z
Lists: pgsql-hackers
On Fri, 07 Mar 2025 13:11:18 -0800 Jeff Davis <pgsql@j-davis.com> wrote: > On Wed, 2025-03-05 at 20:43 -0600, Nathan Bossart wrote: > > I see. Do we provide any suggested next steps for users to assess > > the > > potentially-affected relations? > > I don't know exactly where we should document it, but I've attached a > SQL file that demonstrates what can happen for a PG17->PG18 upgrade, > assuming that we've updated Unicode to 16.0.0 in PG18. > > The change in Unicode that I'm focusing on is the addition of U+A7DC, > which is unassigned in Unicode 15.1 and assigned in Unicode 16, which > lowercases to U+019B. The examples assume that the user is using > unassigned code points in PG17/Unicode15.1 and the PG_C_UTF8 > collation. It seems the consensus is to update unicode in core... FWIW, I'm still 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? -Jeremy
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