Re: ICU Collations and Collation Updates - Mailing list pgsql-general

From Tom Lane
Subject Re: ICU Collations and Collation Updates
Date
Msg-id 1257278.1744641400@sss.pgh.pa.us
Whole thread Raw
In response to Re: ICU Collations and Collation Updates  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: ICU Collations and Collation Updates
Re: ICU Collations and Collation Updates
List pgsql-general
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Mon, 2025-04-14 at 08:28 +0000, Thomas Michael Engelke wrote:
>> Is my understanding correct then in that this way the database
>> collations never change, unless a manual intervention reinitialises the
>> collations and reindexes the database (or appropriate indexes)? How
>> does that process compare to other RDBMS?

> When you update the C library or ICU library and the version changes,
> you get warned by PostgreSQL and have to rebuild indexes.
> So the collations can change whenever you update the respective libraries.
> You would have to build PostgreSQL yourself with a fixed version of ICU
> that you never upgrade if you want to avoid the problem.

Yeah.  AIUI there are two things that ICU does better than libc here:

1. ICU has a fairly well-defined scheme for identifying collation
versions, glibc not so much.  So the collation-changed warnings that
Laurenz mentions are a lot more trustworthy for ICU collations.

2. It's at least *possible* to use your own fixed-version ICU
library if you're desperate enough.  I don't think that would work
too well for libc; you're stuck with what the platform provides.

            regards, tom lane



pgsql-general by date:

Previous
From: Dominique Devienne
Date:
Subject: Re: Event-Triggers for DB owners instead of just SUPERUSER
Next
From: Tom Lane
Date:
Subject: Re: TRUNCATE ONLY with foreign keys and triggers disabled