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

  1. Check the size in COPY_POINTER_FIELD

  2. Rethink regexp engine's backref-related compilation state.

  3. Fix use-after-free issue in regexp engine.

  4. Make regexp engine's backref-related compilation state more bulletproof.

  5. Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.

  6. Avoid generating extra subre tree nodes for capturing parentheses.