~maria-captains/maria/5.3

Viewing all changes in revision 2732.57.16.

  • Committer: timour at askmonty
  • Date: 2012-09-14 08:26:01 UTC
  • mto: This revision was merged to the branch mainline in revision 3576.
  • Revision ID: timour@askmonty.org-20120914082601-ih3fb4tqxl36p2ml
Fix bug lp:1009187, mdev-373, mysql bug#58628

Analysis:
The queries in question use the [unique | index]_subquery execution methods.
These methods reuse the ref keys constructed by create_ref_for_key(). The
way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
store_key elements that represent constants. In particular it doesn't store
the store_key for NULL constants.

The execution of [unique | index]_subquery calls
subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
the left IN argument into a index lookup key, is supposed to detect if
the left IN argument contains NULLs. Since the store_key for the NULL
constant is not copied into the key array, the null is not detected, and
execution erroneously proceeds as if it should look for a complete match.

Solution:
The solution (unlike MySQL) is to reuse already computed information about
NULL presence. Item_in_optimizer::val_int already finds out if the left IN
operand contains NULLs. The fix propagates this to the execution methods
subselect_[unique | index]subquery_engine::exec so it knows if there were
NULL values independent of the presence of keys.

In addition the patch siplifies copy_ref_key() and the logic that hanldes
the case of NULLs in the left IN operand.

expand all expand all

Show diffs side-by-side

added added

removed removed

Lines of Context: