17: lc_collate_is_c() when LC_CTYPE != LC_COLLATE

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: 17: lc_collate_is_c() when LC_CTYPE != LC_COLLATE
Date: 2024-11-06 17:35:27
Message-ID: d5081a7f4f6d425c28dd69d1e09b2e78f149e726.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Due to a very unfortunate copy-and-paste error in 2d819a08a1, for the
libc provider, lc_collate_is_c() is checking the environment's LC_CTYPE
rather than LC_COLLATE :(

This sort of works if LC_COLLATE=C and LC_CTYPE=en_US.utf8 (or another
real locale), because lc_collate_is_c() returns false and it falls
through to strcoll(), which will observe LC_COLLATE.

But if LC_COLLATE=en_US.utf8 and LC_CTYPE=C, then it's wrong results. 

By good fortune, I believe that the latter combination is fairly rare,
which may explain why it evaded manual testing until now. But it's
still pretty bad.

Trivial patch attached, which I intend to commit shortly to 17 only.
The bug does not exist in master due to recent refactoring.

Regards,
Jeff Davis

Attachment Content-Type Size
v1-0001-Fix-lc_collate_is_c-when-LC_COLLATE-LC_CTYPE.patch text/x-patch 915 bytes

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-11-06 18:05:53 BUG #18693: Column names not set when using SELECT STRICT INTO with RECORD type
Previous Message Alexander Korotkov 2024-11-06 17:14:56 Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length