database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-23 03:21:12 +03:00
Code Activity

Improve comment in regc_pg_locale.c.

Browse Source 
Reported-by: Noah Misch <noah@leadboat.com>
Reviewed-by: Noah Misch <noah@leadboat.com>
Discussion: https://postgr.es/m/20250412123430.8c.nmisch@google.com
This commit is contained in:
Jeff Davis
2025-04-16 16:46:16 -07:00
parent 3fae25cbb3
commit b107744ce7
1 changed files with 13 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
src/backend/regex/regc_pg_locale.c
View File

@ -21,22 +21,22 @@
#include "utils/pg_locale.h" #include "utils/pg_locale.h"
/* /*
* To provide as much functionality as possible on a variety of platforms, * For the libc provider, to provide as much functionality as possible on a
* without going so far as to implement everything from scratch, we use * variety of platforms without going so far as to implement everything from
* several implementation strategies depending on the situation: * 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 * 1. In C/POSIX collations, we use hard-wired code. We can't depend on
* the <ctype.h> functions since those will obey LC_CTYPE. Note that these * the <ctype.h> functions since those will obey LC_CTYPE. Note that these
* collations don't give a fig about multibyte characters. * collations don't give a fig about multibyte characters.
* *
* 2. In the "default" collation (which is supposed to obey LC_CTYPE): * 2. When working in UTF8 encoding, we use the <wctype.h> functions.
*
* 2a. When working in UTF8 encoding, we use the <wctype.h> functions.
* This assumes that every platform uses Unicode codepoints directly * 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. * wchar_t is only 16 bits wide, so we have to punt for codepoints > 0xFFFF.
* *
* 2b. In all other encodings, we use the <ctype.h> functions for pg_wchar * 3. In all other encodings, we use the <ctype.h> functions for pg_wchar
* values up to 255, and punt for values above that. This is 100% correct * 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 * only in single-byte encodings such as LATINn. However, non-Unicode
* multibyte encodings are mostly Far Eastern character sets for which the * 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 * the platform's wchar_t representation matches what we do in pg_wchar
* conversions. * conversions.
* *
* 3. Here, we use the locale_t-extended forms of the <wctype.h> and <ctype.h> * As a special case, in the "default" collation, (2) and (3) force ASCII
* functions, under exactly the same cases as #2. * 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
* There is one notable difference between cases 2 and 3: in the "default" * where this matters is treatment of I/i in Turkish, and the behavior is
* collation we force ASCII letters to follow ASCII upcase/downcase rules, * meant to match the upper()/lower() SQL functions.
* 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 * 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 * it could be passed down to here via the regex library's "struct vars" data