Hi Laurenz,
> On 14 Apr 2025, at 19:36, Laurenz Albe wrote:
>
> You cannot "bake in into" PostgreSQL, but you can grab the ICU source,
> install it in /usr/local or similar and build PostgreSQL against that.
> You will have to fiddle with CFLAGS and LDFLAGS so that the build process
> uses the C
On Mon, 2025-04-14 at 19:24 +0200, Paul Foerster wrote:
> Hi Tom, hi Laurenz
> > On 14 Apr 2025, at 16:36, Tom Lane wrote:
> >
> > Laurenz Albe 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.
> [
Hi Tom, hi Laurenz
> On 14 Apr 2025, at 16:36, Tom Lane wrote:
>
> Laurenz Albe 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
>
Le Mon, 14 Apr 2025 10:36:40 -0400,
Tom Lane a écrit :
[…]
> 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.
You're not so stuck with what the plat
Laurenz Albe writes:
> On Mon, 2025-04-14 at 08:28 +, 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)? Ho
On Mon, 2025-04-14 at 08:28 +, Thomas Michael Engelke wrote:
> Where I currently work my colleagues used libc collations before I
> arrived. While using libc collations, they stumbled upon the collation
> update problem after SLES updates (15.4 to 15.5) (collation version
> difference for datab
