Author: Tom Lane <[email protected]>
Branch: master [9d4ca0131] 2017-01-26 12:18:07 -0500
Branch: REL9_6_STABLE [2dfc12647] 2017-01-26 12:17:47 -0500
Branch: REL9_5_STABLE [423ad86f4] 2017-01-26 12:17:47 -0500
Branch: REL9_4_STABLE [2c1976a6c] 2017-01-26 12:17:47 -0500
Branch: REL9_3_STABLE [2e024f83b] 2017-01-26 12:17:47 -0500
Branch: REL9_2_STABLE [fe6120f9b] 2017-01-26 12:17:47 -0500
Ensure that a tsquery like '!foo' matches empty tsvectors.
!foo means "the tsvector does not contain foo", and therefore it should
match an empty tsvector. ts_match_vq() overenthusiastically supposed
that an empty tsvector could never match any query, so it forcibly
returned FALSE, the wrong answer. Remove the premature optimization.
Our behavior on this point was inconsistent, because while seqscans and
GIST index searches both failed to match empty tsvectors, GIN index
searches would find them, since GIN scans don't rely on ts_match_vq().
That makes this certainly a bug, not a debatable definition disagreement,
so back-patch to all supported branches.
Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.
Discussion: https://postgr.es/m/[email protected]
It can tell that the 9.4 and 9.5 patches are identical to each other, and that the 9.6 and master patches are also identical to each other. But there were differences between the two groups.
This is fairly easy to do, if you enforce a policy of requiring cherry-picks to reference the original commit (i.e. requiring -x in the git cherry-pick command).
You can the grep the log for all the commits which contain the commit ID you are interested in (and any that mention those commits).
That's not always that helpful, because you often will want to cherry-pick from another branch than master. E.g. when cherry-picking a change from master into 9.6, 9.5, 9.4, 9.3, 9.2 it'll e.g. often be easier to cherry-pick from 9.3 into 9.2, rather than master into 9.2 (due to conflicts increasing the further back you go). Obviously you could do that manually or script it regardless. But the current heuristics have worked without problems for years, so there seems little reason to change things ;)