]> granicus.if.org Git - postgresql/commit
Fix contrib/pg_trgm's extraction of trigrams from regular expressions.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 22 Feb 2017 20:04:07 +0000 (15:04 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 22 Feb 2017 20:04:07 +0000 (15:04 -0500)
commit53b5a8c131064c3bc8f81d2617e2328487b4fba9
tree00a77385613d78d2f9b0e64e6d19985aebaa618e
parent3f613c6a4073149bb79af8ec82eab9c0a900fd53
Fix contrib/pg_trgm's extraction of trigrams from regular expressions.

The logic for removing excess trigrams from the result was faulty.
It intends to avoid merging the initial and final states of the NFA,
which is necessary, but in testing whether removal of a specific trigram
would cause that, it failed to consider the combined effects of all the
state merges that that trigram's removal would cause.  This could result
in a broken final graph that would never match anything, leading to GIN
or GiST indexscans not finding anything.

To fix, add a "tentParent" field that is used only within this loop,
and set it to show state merges that we are tentatively going to do.
While examining a particular arc, we must chase up through tentParent
links as well as regular parent links (the former can only appear atop
the latter), and we must account for state init/fin flag merges that
haven't actually been done yet.

To simplify the latter, combine the separate init and fin bool fields
into a bitmap flags field.  I also chose to get rid of the "children"
state list, which seems entirely inessential.

Per bug #14563 from Alexey Isayko, which the added test cases are based on.
Back-patch to 9.3 where this code was added.

Report: https://postgr.es/m/20170222111446.1256.67547@wrigleys.postgresql.org
Discussion: https://postgr.es/m/8816.1487787594@sss.pgh.pa.us
contrib/pg_trgm/expected/pg_trgm.out
contrib/pg_trgm/sql/pg_trgm.sql
contrib/pg_trgm/trgm_regexp.c