diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-25 13:00:40 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-25 13:00:40 -0500 |
| commit | 2a0af7fe460eb46f9af996075972bf7c2e3f211d (patch) | |
| tree | dc99ebbf913c05e67796401ebbd1cabe4fad349b /src/backend/regex/re_syntax.n | |
| parent | 6b40d9bdbdc9f873868b0ddecacd9a307fc8ee26 (diff) | |
| download | postgresql-2a0af7fe460eb46f9af996075972bf7c2e3f211d.tar.gz postgresql-2a0af7fe460eb46f9af996075972bf7c2e3f211d.zip | |
Allow complemented character class escapes within regex brackets.
The complement-class escapes \D, \S, \W are now allowed within
bracket expressions. There is no semantic difficulty with doing
that, but the rather hokey macro-expansion-based implementation
previously used here couldn't cope.
Also, invent "word" as an allowed character class name, thus "\w"
is now equivalent to "[[:word:]]" outside brackets, or "[:word:]"
within brackets. POSIX allows such implementation-specific
extensions, and the same name is used in e.g. bash.
One surprising compatibility issue this raises is that constructs
such as "[\w-_]" are now disallowed, as our documentation has always
said they should be: character classes can't be endpoints of a range.
Previously, because \w was just a macro for "[:alnum:]_", such a
construct was read as "[[:alnum:]_-_]", so it was accepted so long as
the character after "-" was numerically greater than or equal to "_".
Some implementation cleanup along the way:
* Remove the lexnest() hack, and in consequence clean up wordchrs()
to not interact with the lexer.
* Fix colorcomplement() to not be O(N^2) in the number of colors
involved.
* Get rid of useless-as-far-as-I-can-see calls of element()
on single-character character element names in brackpart().
element() always maps these to the character itself, and things
would be quite broken if it didn't --- should "[a]" match something
different than "a" does? Besides, the shortcut path in brackpart()
wasn't doing this anyway, making it even more inconsistent.
Discussion: https://postgr.es/m/2845172.1613674385@sss.pgh.pa.us
Discussion: https://postgr.es/m/3220564.1613859619@sss.pgh.pa.us
Diffstat (limited to 'src/backend/regex/re_syntax.n')
| -rw-r--r-- | src/backend/regex/re_syntax.n | 13 |
1 files changed, 4 insertions, 9 deletions
diff --git a/src/backend/regex/re_syntax.n b/src/backend/regex/re_syntax.n index 4621bfc25f4..1afaa7cce7c 100644 --- a/src/backend/regex/re_syntax.n +++ b/src/backend/regex/re_syntax.n @@ -519,15 +519,10 @@ character classes: (note underscore) .RE .PP -Within bracket expressions, `\fB\ed\fR', `\fB\es\fR', -and `\fB\ew\fR'\& -lose their outer brackets, -and `\fB\eD\fR', `\fB\eS\fR', -and `\fB\eW\fR'\& -are illegal. -.VS 8.2 -(So, for example, \fB[a-c\ed]\fR is equivalent to \fB[a-c[:digit:]]\fR. -Also, \fB[a-c\eD]\fR, which is equivalent to \fB[a-c^[:digit:]]\fR, is illegal.) +The class-shorthand escapes also work within bracket expressions, +although the definitions shown above are not quite syntactically +valid in that context. +For example, \fB[a-c\ed]\fR is equivalent to \fB[a-c[:digit:]]\fR. .VE 8.2 .PP A constraint escape (AREs only) is a constraint, |