Re: Update Unicode data to Unicode 16.0.0
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>,
Jeremy Schneider <schneider@ardentperf.com>, Joe Conway <mail@joeconway.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Nathan Bossart <nathandbossart@gmail.com>,
Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-18T20:30:48Z
Lists: pgsql-hackers
On Tue, Mar 18, 2025 at 3:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > That approach works only if you sit on Unicode 15.1 *forever*. > The impracticality of that seems obvious to me. Sooner or later > you will need to update, and then you are going to suffer pain. I completely agree. > The short answer is that "immutable" = "doesn't change till the heat > death of the universe" is a definition that is not useful when > dealing with this type of data. Other people determine the reality > that you have to deal with. I think that's mostly true because of lack of versioning capabilities, or crappy versioning practices. glibc, AIUI, just disclaims collation stability: if you're fool enough to sort anything with one of their collations, that's on you. To me, that seems like an obviously user-hostile position, as if it were reasonable to suppose that an algorithm whose whole purpose is to implement a sort order would not be used for, uh, sorting. Or at least not any sort of sorting where you don't immediately throw away the results (and then why did you bother?). ICU doesn't seem to be entirely stable, either. But none of that means stability isn't a valuable property. It just means people have done a bad job implementing it. If we give people the ability to execute operation X using ICU 15.1 or ICU 16.0, they're still *eventually* going to have to migrate forward to ICU 16.0 or some later version, because we're probably not going to keep ICU 15.1 until the heat death of the universe. But we allow people to not have that update forced upon them at the same time they're trying to change other things, and that's pretty darn useful. That's why extensions have separate versioning from the server, for instance. -- Robert Haas EDB: http://www.enterprisedb.com
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