Re: pg_collation.collversion for C.UTF-8

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com>
Cc: "Jeff Davis" <pgsql(at)j-davis(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_collation.collversion for C.UTF-8
Date: 2023-06-21 17:07:14
Message-ID: e7c4b2cc-3e4d-4df4-967d-d1bf20853736@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-06-21 17:13:01 Re: EBCDIC sorting as a use case for ICU rules
Previous Message Andres Freund 2023-06-21 16:50:00 Re: Remove deprecation warnings when compiling PG ~13 with OpenSSL 3.0~