diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-09-22 11:35:12 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-09-22 11:35:12 -0400 |
| commit | ed87e1980706975e7aa412bee200087774c5ff22 (patch) | |
| tree | 8e85249b86ffc0de824aa779efdf8d67ed5a59e8 /src/backend/regex/regc_pg_locale.c | |
| parent | 85feb77aa09cda9ff3e12cf95c757c499dc25343 (diff) | |
| download | postgresql-ed87e1980706975e7aa412bee200087774c5ff22.tar.gz postgresql-ed87e1980706975e7aa412bee200087774c5ff22.zip | |
Mop-up for commit 85feb77aa09cda9ff3e12cf95c757c499dc25343.
Adjust commentary in regc_pg_locale.c to remove mention of the possibility
of not having <wctype.h> functions, since we no longer consider that.
Eliminate duplicate code in wparser_def.c by generalizing the p_iswhat
macro to take a parameter saying what to return for non-ASCII chars
in C locale. (That's not really a consequence of the
USE_WIDE_UPPER_LOWER-ectomy, but I noticed it while doing that.)
Diffstat (limited to 'src/backend/regex/regc_pg_locale.c')
| -rw-r--r-- | src/backend/regex/regc_pg_locale.c | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/src/backend/regex/regc_pg_locale.c b/src/backend/regex/regc_pg_locale.c index b2122e9e8fa..e39ee7ae09f 100644 --- a/src/backend/regex/regc_pg_locale.c +++ b/src/backend/regex/regc_pg_locale.c @@ -29,20 +29,20 @@ * * 2. In the "default" collation (which is supposed to obey LC_CTYPE): * - * 2a. When working in UTF8 encoding, we use the <wctype.h> functions if - * available. This assumes that every platform uses Unicode codepoints - * directly as the wchar_t representation of Unicode. On some platforms + * 2a. When working in UTF8 encoding, we use the <wctype.h> functions. + * This assumes that every platform uses Unicode codepoints directly + * as the wchar_t representation of Unicode. On some platforms * wchar_t is only 16 bits wide, so we have to punt for codepoints > 0xFFFF. * - * 2b. In all other encodings, or on machines that lack <wctype.h>, we use - * the <ctype.h> functions for pg_wchar values up to 255, and punt for values - * above that. This is only 100% correct in single-byte encodings such as - * LATINn. However, non-Unicode multibyte encodings are mostly Far Eastern - * character sets for which the properties being tested here aren't very - * relevant for higher code values anyway. The difficulty with using the - * <wctype.h> functions with non-Unicode multibyte encodings is that we can - * have no certainty that the platform's wchar_t representation matches - * what we do in pg_wchar conversions. + * 2b. 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 + * only in single-byte encodings such as LATINn. However, non-Unicode + * multibyte encodings are mostly Far Eastern character sets for which the + * properties being tested here aren't very relevant for higher code values + * anyway. The difficulty with using the <wctype.h> functions with + * non-Unicode multibyte encodings is that we can have no certainty that + * the platform's wchar_t representation matches what we do in pg_wchar + * conversions. * * 3. Other collations are only supported on platforms that HAVE_LOCALE_T. * Here, we use the locale_t-extended forms of the <wctype.h> and <ctype.h> |