Re: Assert triggered during RE_compile_and_cache
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-08-08T18:44:02Z
Lists: pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.com> writes:
> There are a few changes which appear correct to me, but I don't know if you expected them:
> select regexp_match('hko', '((((?<!.))))(.(\3)(\1.))');
> - regexp_match
> ---------------
> -
> + regexp_match
> +--------------------
> + {"","","",hk,"",k}
> (1 row)
Yes, this one is a consequence of 4aea704a5 (Fix semantics of regular
expression back-references). The lookbehind constraint should not be
applied within the back-ref.
> select 'nigqvigqvee' !~ '(())((\2)\2)(?:([^\W]))';
> -ERROR: invalid regular expression: invalid escape \ sequence
> + ?column?
> +----------
> + f
> +(1 row)
> +
and this one of 2a0af7fe4 (Allow complemented character class escapes
within regex brackets).
> select regexp_replace('tl', '.{0}?(((?<![^][^]{1}?)))(.)\2{6}?', 'jx', 'mt');
> regexp_replace
> ----------------
> - tl
> + jxl
> (1 row)
This looks like also a consequence of 4aea704a5.
regards, tom lane
Commits
-
Check the size in COPY_POINTER_FIELD
- c1132aae336c 15.0 cited
-
Rethink regexp engine's backref-related compilation state.
- 5227d9989672 14.0 landed
- 00116dee5ad4 15.0 landed
-
Fix use-after-free issue in regexp engine.
- f42ea8350db2 14.0 landed
- cc1868799c83 15.0 landed
-
Make regexp engine's backref-related compilation state more bulletproof.
- cb76fbd7ec87 15.0 landed
- 5e6ad63c6db7 14.0 landed
-
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
- ba9f665a4413 13.4 cited
-
Avoid generating extra subre tree nodes for capturing parentheses.
- ea1268f6301c 14.0 cited