diff options
author | Ole John Aske <ole.john.aske@oracle.com> | 2011-02-01 15:19:34 +0100 |
---|---|---|
committer | Ole John Aske <ole.john.aske@oracle.com> | 2011-02-01 15:19:34 +0100 |
commit | ed74edada2500531bfb661d3a024b3ac2bd883a8 (patch) | |
tree | efa195d85fbc4956bdbea78a1a98ffef77165fd9 /sql/sql_client.cc | |
parent | 4b8888f6f00251ebc5559d9f0ac1b15f525ba05c (diff) | |
download | mariadb-git-ed74edada2500531bfb661d3a024b3ac2bd883a8.tar.gz |
Fix for bug#58490, 'Incorrect result in multi level OUTER JOIN
in combination with IS NULL'
As this bug is a duplicate of bug#49322, it also includes test cases
covering this bugreport
Qualifying an OUTER JOIN with the condition 'WHERE <column> IS NULL',
where <column> is declared as 'NOT NULL' causes the
'not_exists_optimize' to be enabled by the optimizer.
In evaluate_join_record() the 'not_exists_optimize' caused
'NESTED_LOOP_NO_MORE_ROWS' to be returned immediately
when a matching row was found.
However, as the 'not_exists_optimize' is derived from
'JOIN_TAB::select_cond', the usual rules for condition guards
also applies for 'not_exist_optimize'. It is therefore incorrect
to check 'not_exists_optimize' without ensuring that all guards
protecting it is 'open'.
This fix uses the fact that 'not_exists_optimize' is derived from
a 'is_null' predicate term in 'tab->select_cond'. Furthermore,
'is_null' will evaluate to 'false' for any 'non-null' rows
once all guards protecting the is_null is open.
We can use this knowledge as an implicit guard check for the
'not_exists_optimize' by moving 'if (...not_exists_optimize)'
inside the handling of 'select_cond==false'. It will then
not take effect before its guards are open.
We also add an assert which requires that a
'not_exists_optimize' always comes together with
a select_cond. (containing 'is_null').
Diffstat (limited to 'sql/sql_client.cc')
0 files changed, 0 insertions, 0 deletions