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

  1. pg_upgrade: Fix memory leak in check_for_unicode_update().

  2. pg_upgrade check for Unicode-dependent relations.

  3. Update Unicode data to Unicode 16.0.0