diff options
Diffstat (limited to 'src/backend/regex/regc_pg_locale.c')
| -rw-r--r-- | src/backend/regex/regc_pg_locale.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/src/backend/regex/regc_pg_locale.c b/src/backend/regex/regc_pg_locale.c index 425c278de43..6b2e38e165d 100644 --- a/src/backend/regex/regc_pg_locale.c +++ b/src/backend/regex/regc_pg_locale.c @@ -24,7 +24,7 @@ * several implementation strategies depending on the situation: * * 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. * * 2. In the "default" collation (which is supposed to obey LC_CTYPE): @@ -36,10 +36,10 @@ * * 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 + * 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 + * 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. @@ -730,7 +730,7 @@ store_match(pg_ctype_cache *pcc, pg_wchar chr1, int nchrs) /* * Given a probe function (e.g., pg_wc_isalpha) get a struct cvec for all - * chrs satisfying the probe function. The active collation is the one + * chrs satisfying the probe function. The active collation is the one * previously set by pg_set_regex_collation. Return NULL if out of memory. * * Note that the result must not be freed or modified by caller. @@ -777,7 +777,7 @@ pg_ctype_get_cache(pg_wc_probefunc probefunc) * UTF8 go up to 0x7FF, which is a pretty arbitrary cutoff but we cannot * extend it as far as we'd like (say, 0xFFFF, the end of the Basic * Multilingual Plane) without creating significant performance issues due - * to too many characters being fed through the colormap code. This will + * to too many characters being fed through the colormap code. This will * need redesign to fix reasonably, but at least for the moment we have * all common European languages covered. Otherwise (not C, not UTF8) go * up to 255. These limits are interrelated with restrictions discussed |