• unknown's avatar
    Fix bug lp:1009187, mdev-373, mysql bug#58628 · f89d6a6f
    unknown authored
    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.
    f89d6a6f
item_subselect.h 18.6 KB