Tom Lane 6eaf7e5bea 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 173e29aa5d. 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.		2014-09-23 20:26:21 -04:00
..
examples	Update copyright for 2014	2014-01-07 16:05:30 -05:00
isolation	Fix FOR UPDATE NOWAIT on updated tuple chains	2014-08-27 19:15:18 -04:00
locale	Rename 'gmake' to 'make' in docs and recommended commands	2014-02-12 17:29:19 -05:00
mb	Lots of doc corrections.	2012-04-23 22:43:09 -04:00
performance	Run newly-configured perltidy script on Perl files.	2012-07-04 21:47:49 -04:00
perl	Handle old versions of Test::More	2014-09-10 20:52:50 -04:00
regress	Fix incorrect search for "x?" style matches in creviterdissect().	2014-09-23 20:26:21 -04:00
thread	Update copyright for 2014	2014-01-07 16:05:30 -05:00
Makefile	Add isolation test to check-world and installcheck-world	2012-03-05 20:19:20 +02:00