Horton

Re: Update Unicode data to Unicode 16.0.0

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Joe Conway <mail@joeconway.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Jeremy Schneider <schneider@ardentperf.com>, Nathan Bossart <nathandbossart@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-19T02:33:00Z
Lists: pgsql-hackers 
On Tue, 2025-03-18 at 21:34 -0400, Robert Haas wrote:
> But I could not disagree more strongly with the idea that this
> problem
> is 99% solved. That doesn't seem remotely true to me. I'm not sure
> the
> problem is 1% solved.

If we compare the following two problems:

  A. With glibc or ICU, every text index, including primary keys, are
highly vulnerable to inconsistencies after an OS upgrade, even if
there's no Postgres upgrade; vs.

  B. With the builtin provider, only expression indexes and a few other
things are vulnerable, only during a major version upgrade, and mostly
(but not entirely) when using recently-assigned Cased letters.

To me, problem A seems about 100 times worse than B almost any way I
can imagine measuring it: number of objects vulnerable, severity of the
problem when it does happen, likelihood of a vulnerable object having
an actual problem, etc. If you disagree, I'd like to hear more.

Regards,
	Jeff Davis

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