Re: ICU Collations and Collation Updates

From: Paul Foerster <paul(dot)foerster(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Cybertec Schönig & Schönig GmbH <laurenz(dot)albe(at)cybertec(dot)at>, 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 17:24:29
Message-ID: 23A7395F-6134-4D9E-8489-8F3BCE49E156@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom, hi Laurenz

> On 14 Apr 2025, at 16:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
>> You would have to build PostgreSQL yourself with a fixed version of ICU
>> that you never upgrade if you want to avoid the problem.
[...]
> 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.

That topic is interesting because I have a huge problem finding a downtime window for our applications to rebuild after the SLES upgrades. I am in the process of slowly changing everything to ICU. But limiting downtime is essential for me.

We always build the PostgreSQL software from source, so if there's a way to bake the libicu directly into the software to never change it again (beside from recompiling of course), even when building new PostgreSQL versions, I'd very much appreciate if if you could let me know how I would do that.

The necessity for reindex is a huge problem for us.

Cheers,
Paul

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2025-04-14 17:36:36 Re: ICU Collations and Collation Updates
Previous Message Jehan-Guillaume de Rorthais 2025-04-14 17:18:46 Re: ICU Collations and Collation Updates