diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-09-05 17:06:29 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-09-05 17:06:29 -0400 |
commit | c54159d44ceaba26ceda9fea1804f0de122a8f30 (patch) | |
tree | eaab96027f054cf5ff864d0745e446e8b8e13544 /src/include/regex/regcustom.h | |
parent | f80049f76a32858601510eaaef19ab8160e4c9b3 (diff) | |
download | postgresql-c54159d44ceaba26ceda9fea1804f0de122a8f30.tar.gz postgresql-c54159d44ceaba26ceda9fea1804f0de122a8f30.zip |
Make locale-dependent regex character classes work for large char codes.
Previously, we failed to recognize Unicode characters above U+7FF as
being members of locale-dependent character classes such as [[:alpha:]].
(Actually, the same problem occurs for large pg_wchar values in any
multibyte encoding, but UTF8 is the only case people have actually
complained about.) It's impractical to get Spencer's original code to
handle character classes or ranges containing many thousands of characters,
because it insists on considering each member character individually at
regex compile time, whether or not the character will ever be of interest
at run time. To fix, choose a cutoff point MAX_SIMPLE_CHR below which
we process characters individually as before, and deal with entire ranges
or classes as single entities above that. We can actually make things
cheaper than before for chars below the cutoff, because the color map can
now be a simple linear array for those chars, rather than the multilevel
tree structure Spencer designed. It's more expensive than before for
chars above the cutoff, because we must do a binary search in a list of
high chars and char ranges used in the regex pattern, plus call iswalpha()
and friends for each locale-dependent character class used in the pattern.
However, multibyte encodings are normally designed to give smaller codes
to popular characters, so that we can expect that the slow path will be
taken relatively infrequently. In any case, the speed penalty appears
minor except when we have to apply iswalpha() etc. to high character codes
at runtime --- and the previous coding gave wrong answers for those cases,
so whether it was faster is moot.
Tom Lane, reviewed by Heikki Linnakangas
Discussion: <15563.1471913698@sss.pgh.pa.us>
Diffstat (limited to 'src/include/regex/regcustom.h')
-rw-r--r-- | src/include/regex/regcustom.h | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/src/include/regex/regcustom.h b/src/include/regex/regcustom.h index 459851a7f6b..04a1893c806 100644 --- a/src/include/regex/regcustom.h +++ b/src/include/regex/regcustom.h @@ -77,6 +77,16 @@ typedef unsigned uchr; /* unsigned type that will hold a chr */ */ #define CHR_IS_IN_RANGE(c) ((c) <= CHR_MAX) +/* + * MAX_SIMPLE_CHR is the cutoff between "simple" and "complicated" processing + * in the color map logic. It should usually be chosen high enough to ensure + * that all common characters are <= MAX_SIMPLE_CHR. However, very large + * values will be counterproductive since they cause more regex setup time. + * Also, small values can be helpful for testing the high-color-map logic + * with plain old ASCII input. + */ +#define MAX_SIMPLE_CHR 0x7FF /* suitable value for Unicode */ + /* functions operating on chr */ #define iscalnum(x) pg_wc_isalnum(x) #define iscalpha(x) pg_wc_isalpha(x) |