From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Thomas Michael Engelke <thomas(dot)engelke(at)posteo(dot)de>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: ICU Collations and Collation Updates |
Date: | 2025-04-14 14:36:40 |
Message-ID: | 1257278.1744641400@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-14 14:45:01 | Re: TRUNCATE ONLY with foreign keys and triggers disabled |
Previous Message | Dominique Devienne | 2025-04-14 11:08:20 | Re: Event-Triggers for DB owners instead of just SUPERUSER |