| Ticket UUID: | 5ea71fdcd3291c38dff80d6ccdaf30f4969316e4 | ||
| Title: | Regexp fails to enforce LACON restrictions inside nested parentheses | ||
| Type: | Bug | Created on: | 2015-11-07 18:31:03 |
| Submitter: | tgl | Assigned to: | nobody |
| Subsystem: | 43. Regexp | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2026-10-11 08:04:06 |
| Status: | Open | Closed by: | nobody |
| Resolution: | None | Closed on: | |
| Version: | 8.6.18, 9.0.5, 9.1.0 | ||
| Description: | ||||
Per the manual, backrefs are not allowed inside lookahead constraints, and all parentheses therein are considered non-capturing. But the regexp parser forgets these restrictions when it recurses to enter a parenthesized subexpression inside a LACON. So we get silliness like this (tested with 8.6.4):
% regexp -inline {x(\w)(?=(\1))} {xyz}
xy y
% regexp -inline {x(?=((foo)))} {xfoobar}
x {}
Fix is a one-liner, see attached patch, which is a Tcl-ified version of
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a43b4ab1111ca5e5f40a2ddd8e56bf999b9fdad9
| ||||
| User Comments: | ||||
serhiy.storchaka added on 2026-10-11 08:04:06:
Still the same in 8.6, 9.0 and 9.1. Proposed fix in branch regexp-lacon-nested-parens: your patch. Both examples now behave as in PostgreSQL: the first one gives "invalid backreference number", the second one matches x without submatches. Tests reg-6.21 to 6.24. This is a breaking change. Parentheses nested in a lookahead constraint no longer count as capturing, so the following subexpressions are renumbered, and REs with a backref inside a lookahead constraint no longer compile. Both are what re_syntax.n has always documented, but existing code may rely on the old behaviour. Code that used non-capturing groups (?:...) inside lookahead constraints, the workaround for this bug, is not affected. | ||||
Attachments:
- laconfix.patch [download] added by tgl on 2015-11-07 18:31:39. [details]