From 9724181f715ce3468e9342763fadde450db08d26 Mon Sep 17 00:00:00 2001 From: Jeff Davis Date: Tue, 15 Apr 2025 15:04:37 -0700 Subject: [PATCH v2 1/3] Improve comment in regc_pg_locale.c. Reported-by: Noah Misch Discussion: https://postgr.es/m/20250412123430.8c.nmisch@google.com --- src/backend/regex/regc_pg_locale.c | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/src/backend/regex/regc_pg_locale.c b/src/backend/regex/regc_pg_locale.c index ed7411df83d..31d8ba0322a 100644 --- a/src/backend/regex/regc_pg_locale.c +++ b/src/backend/regex/regc_pg_locale.c @@ -21,22 +21,22 @@ #include "utils/pg_locale.h" /* - * To provide as much functionality as possible on a variety of platforms, - * without going so far as to implement everything from scratch, we use - * several implementation strategies depending on the situation: + * For the libc provider, to provide as much functionality as possible on a + * variety of platforms without going so far as to implement everything from + * scratch, we use several implementation strategies depending on the + * situation: * * 1. In C/POSIX collations, we use hard-wired code. We can't depend on * the functions since those will obey LC_CTYPE. Note that these * collations don't give a fig about multibyte characters. * - * 2. In the "default" collation (which is supposed to obey LC_CTYPE): - * - * 2a. When working in UTF8 encoding, we use the functions. + * 2. When working in UTF8 encoding, we use the functions. * This assumes that every platform uses Unicode codepoints directly - * as the wchar_t representation of Unicode. On some platforms + * as the wchar_t representation of Unicode. (XXX: ICU makes this assumption + * even for non-UTF8 encodings, which may be a problem.) On some platforms * wchar_t is only 16 bits wide, so we have to punt for codepoints > 0xFFFF. * - * 2b. In all other encodings, we use the functions for pg_wchar + * 3. In all other encodings, we use the functions for pg_wchar * values up to 255, and punt for values above that. This is 100% correct * only in single-byte encodings such as LATINn. However, non-Unicode * multibyte encodings are mostly Far Eastern character sets for which the @@ -46,14 +46,11 @@ * the platform's wchar_t representation matches what we do in pg_wchar * conversions. * - * 3. Here, we use the locale_t-extended forms of the and - * functions, under exactly the same cases as #2. - * - * There is one notable difference between cases 2 and 3: in the "default" - * collation we force ASCII letters to follow ASCII upcase/downcase rules, - * while in a non-default collation we just let the library functions do what - * they will. The case where this matters is treatment of I/i in Turkish, - * and the behavior is meant to match the upper()/lower() SQL functions. + * As a special case, in the "default" collation we force ASCII letters to + * follow ASCII upcase/downcase rules, while in a non-default collation we + * just let the library functions do what they will. The case where this + * matters is treatment of I/i in Turkish, and the behavior is meant to match + * the upper()/lower() SQL functions. * * We store the active collation setting in static variables. In principle * it could be passed down to here via the regex library's "struct vars" data -- 2.34.1