pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jeff.janes@gmail.com
Cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #14623: pg_trgm doesn't correctly process some regexp with negative lookahead
Date: Thu, 13 Apr 2017 15:24:21 -0400
Message-ID: <21076.1492111461@sss.pgh.pa.us> (raw)
In-Reply-To: <20170413180503.25948.94871@wrigleys.postgresql.org>
References: <20170413180503.25948.94871@wrigleys.postgresql.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>

jeff.janes@gmail.com writes:
> This simplified case is easy to reproduce back to at least 9.4, and is still
> present in 10dev HEAD.  Matches are missed when using the trgm index, but
> not when doing the full table scan.

> select * from foobar where x  ~ 'eldrazi (?!scion)'; -- returns 0 rows

> The trigrams seem to be extracted correctly, but the graph stuffed into
> extra_data is not correct.  Looking at /tmp/packed.dot, there are no arrays
> pointing to the successful termination state s1.  Instead, I get lead to a
> dead-end state s7.

Hm.  I think what is happening here is that regexport.c is being too
simplistic by ignoring LACON arcs.  Because it does so, there's actually
no path in the exported search NFA that can reach the success state,
which explains your observation of the lack of such a path in
/tmp/packed.dot.  It's not entirely unreasonable for pg_trgm to be
assuming that such a path must exist.

What regexport.c should be doing is assuming that every LACON constraint
succeeds, hence treating such an arc as a traversable but
zero-input-consuming arc.

Since there's no notion of zero input consumption in the exported
representation, we're going to need some logic in regexport.c to
convert that (by traversing to the arc target state and emitting
its output arcs, possibly recursively).

> If I change the regexp to 'eldrazi (?!s)', then bug goes away, and
> /tmp/packed.dot shows the correct graph pointing to s1.

That seems to be because processlacons will simplify a single-character
LACON into a plain AHEAD/BEHIND constraint, which leads to an NFA that
doesn't confuse the export logic.

			regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs



view thread (7+ messages)  latest in thread

Message-ID: <21076.1492111461@sss.pgh.pa.us>
Permalink:  ../21076.1492111461@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/21076.1492111461@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, jeff.janes@gmail.com
  Subject: Re: BUG #14623: pg_trgm doesn't correctly process some regexp with negative lookahead
  In-Reply-To: <21076.1492111461@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox