aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gist.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2014-09-23 20:25:36 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2014-09-23 20:25:36 -0400
commitbbfdf5d75cd88522a3258ea7ec8d25cd51c35180 (patch)
treea8e8b4ae7ae136f657eea5bd5b68f341a4387e18 /src/backend/access/gist/gist.c
parente35db342aa6a67181d54b09cb80d088805a5f408 (diff)
downloadpostgresql-bbfdf5d75cd88522a3258ea7ec8d25cd51c35180.tar.gz
postgresql-bbfdf5d75cd88522a3258ea7ec8d25cd51c35180.zip
Fix incorrect search for "x?" style matches in creviterdissect().
When the number of allowed iterations is limited (either a "?" quantifier or a bound expression), the last sub-match has to reach to the end of the target string. The previous coding here first tried the shortest possible match (one character, usually) and then gave up and back-tracked if that didn't work, typically leading to failure to match overall, as shown in bug #11478 from Christoph Berg. The minimum change to fix that would be to not decrement k before "goto backtrack"; but that would be a pretty stupid solution, because we'd laboriously try each possible sub-match length before finally discovering that only ending at the end can work. Instead, force the sub-match endpoint limit up to the end for even the first shortest() call if we cannot have any more sub-matches after this one. Bug introduced in my rewrite that added the iterdissect logic, commit 173e29aa5deefd9e71c183583ba37805c8102a72. The shortest-first search code was too closely modeled on the longest-first code, which hasn't got this issue since it tries a match reaching to the end to start with anyway. Back-patch to all affected branches.
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions