Re: BUG #18708: regex problem: (?:[^\d\D]){0} asserts with "lp->nouts == 0 && rp->nins == 0"

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: dhyan@nataraj.su, pgsql-bugs@lists.postgresql.org
Date: 2024-11-15T02:14:27Z
Lists: pgsql-bugs

Attachments

I wrote:
> So I think the right thing to do is to fix colorcomplement() so
> that it still produces some arc between its "from" and "to"
> states, keeping the graph connected until we finish parsing the
> regex.  It has to be a dummy arc that can't match anything, of
> course.  We can throw away such an arc once we get to regex
> optimization, because we don't need delsub() to work anymore.

> In the attached draft patch I represented the dummy arc as a PLAIN
> arc with a new fake color BLACK.  Another way to do it could be to
> introduce a new arc "type" value, but that seemed like it would
> involve touching more code.

After thinking awhile longer, I decided to try it that way (with
a new arc type), and I believe I like the result better after all.
It's just a few lines more code, and I think it's more robust.
Up to now PLAIN arcs always matched exactly one character,
so the first version was putting a major dent in their semantics.
We got rid of the bogus arcs before doing anything that really leans
hard on arc semantics, but still it seems messy.  Hence v2 attached.

I'm not especially in love with the CANTMATCH arc type name, but
other possibilities such as DUMMY or NOMATCH felt too generic.
Better ideas anyone?

			regards, tom lane

Commits

  1. Fix recently-exposed portability issue in regex optimization.

  2. Avoid assertion due to disconnected NFA sub-graphs in regex parsing.

  3. Fix recovery conflict SIGUSR1 handling.

  4. Redesign interrupt/cancel API for regex engine.

  5. Use MemoryContext API for regex memory management.

  6. Invent "rainbow" arcs within the regex engine.