Re: Bizarre behavior of \w in a regular expression bracket construct

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Joel Jacobson <joel@compiler.org>, pgsql-hackers@lists.postgresql.org
Date: 2021-02-21T17:39:45Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> It looks like the interpretation of these other engines is that [\d-a]
> is the set of \d, the literal character "-", and the literal character
> "a".  In other words, the - preceded by \d or \w (or any other character
> class, I guess?) loses its special meaning of identifying a character
> range.

Yeah.  While I can see the attraction of being picky about this,
I can also see the attraction of being more compatible with other
engines.  Should we relax this?

A quick experiment with perl shows that its opinion is "if the
atom before or after a potentially range-defining dash is a
character class, then take the dash as an ordinary character".
(This confirms Joel's result, and also I found that e.g. [3-\w]
treats the dash as a literal character.)

> This one I didn't understand:
>> ^([\W])$   | pg     |

I think Joel just forgot to mark that as ERROR.  It certainly
doesn't work in our engine today (though I'm nearly done with
a patch to fix that).

			regards, tom lane



Commits

  1. Doc: remove src/backend/regex/re_syntax.n.

  2. Change regex \D and \W shorthands to always match newlines.

  3. Allow complemented character class escapes within regex brackets.