Re: pg_collation.collversion for C.UTF-8 - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: pg_collation.collversion for C.UTF-8
Date
Msg-id e7c4b2cc-3e4d-4df4-967d-d1bf20853736@manitou-mail.org
Whole thread Raw
In response to Re: pg_collation.collversion for C.UTF-8  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
    Thomas Munro wrote:

> What could we do that would be helpful here, without affecting users
> of the "true" C.UTF-8 for the rest of time?  This is a Debian (+
> downstream distro) only problem as far as we know so far, and only
> for Debian 11 and older.

It seems to include RedHat-based distros as well.

According to https://bugzilla.redhat.com/show_bug.cgi?id=902094
C.utf8 was added in 2015 and backported down to Fedora 22.
RHEL8 / CentOS 8 / Rocky8 provide glibc 2.28 with a C.utf8
locale. We can reasonably suspect that they've been using the same
kind of patches as Debian before version 12, with not all codepoints
being sorted bytewise.

RHEL9 comes with glibc 2.34 according to distrowatch [1] and the
announcement [2], so presumably it also lacks the "real" C.utf8
with bytewise sorting that glibc 2.35 upstream added.


[1] https://distrowatch.com/table.php?distribution=redhat
[2]
https://developers.redhat.com/articles/2022/05/18/whats-new-red-hat-enterprise-linux-9


Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: EBCDIC sorting as a use case for ICU rules