Re: Update Unicode data to Unicode 16.0.0

On Tue, Mar 18, 2025 at 3:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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