• Gleb Shchepa's avatar
    Bug #39069: <row constructor> IN <table-subquery> seriously · b41c1a45
    Gleb Shchepa authored
                messed up
    
    "ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.
    
    Item_in_subselect::row_value_transformer rewrites "ROW(...)
    IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
    form.
    For a subquery from the DUAL pseudotable resulting HAVING
    condition is an expression on constant values, so further
    transformation with optimize_cond() eliminates this HAVING
    condition and resets JOIN::having to NULL.
    Then JOIN::exec treated that NULL as an always-true-HAVING
    and that caused a bug.
    
    To distinguish an optimized out "HAVING TRUE" clause from
    "HAVING FALSE" we already have the JOIN::having_value flag.
    However, JOIN::exec() ignored JOIN::having_value as described
    above as if it always set to COND_TRUE.
    
    The JOIN::exec method has been modified to take into account
    the value of the JOIN::having_value field.
    b41c1a45
subselect3.result 29 KB