diff options
author | unknown <timour@askmonty.org> | 2011-08-23 00:00:13 +0300 |
---|---|---|
committer | unknown <timour@askmonty.org> | 2011-08-23 00:00:13 +0300 |
commit | 9e60b55fd0ff37527ca83e590d1c5386dfa788d6 (patch) | |
tree | b94b534841c0b945301cc410863331323f092645 /sql/sql_cursor.h | |
parent | aab970f5e16a1dbb308cfc13d47d3b863143811f (diff) | |
download | mariadb-git-9e60b55fd0ff37527ca83e590d1c5386dfa788d6.tar.gz |
Fix bug lp:825095
Analysis:
Partial matching is used even when there are no NULLs in
a materialized subquery, as long as the left NOT IN operand
may contain NULL values.
This case was not handled correctly in two different places.
First, the implementation of parital matching did not clear
the set of matching columns when the merge process advanced
to the next row.
Second, there is no need to perform partial matching at all
when the left operand has no NULLs.
Solution:
First fix subselect_rowid_merge_engine::partial_match() to
properly cleanup the bitmap of matching keys when advancing
to the next row.
Second, change subselect_partial_match_engine::exec() so
that when the materialized subquery doesn't contain any
NULLs, and the left operand of [NOT] IN doesn't contain
NULLs either, the method returns without doing any
unnecessary partial matching. The correct result in this
case is in Item::in_value.
Diffstat (limited to 'sql/sql_cursor.h')
0 files changed, 0 insertions, 0 deletions