This bug could lead to wrong result sets for a query over a
materialized derived table or view accessed by a multi-component
key.
It happened because the function get_next_field_for_derived_key
was supposed to update its argument, and it did not do it.
Also:
1. simplified the code of the function mysql_derived_merge_for_insert.
2. moved merge of views/dt for multi-update/delete to the prepare stage.
3. the list of the references to the candidates for semi-join now is
allocated in the statement memory.
The attribute not_null_tables could be calculated incorrectly in the
function SELECT_LEX::update_used_tables for queries over views
with row items in the WHERE clause. It happened because no
implementation of the virtual callback function eval_not_null_tables
was provided for the class Item_row.
Also slightly optimized the code calculating the value of the maybe_null
flag for tables in the function SELECT_LEX::update_used_tables.
The bitmap of used tables must be evaluated for the select list of every
materialized derived table / view and saved in a dedicated field.
This is also applied to materialized subqueries.
Missing initialization of the bitmap not_null_tables_cache to 0
in the function Item_func::eval_not_null_tables caused this bug.
This function is called indirectly from the function
SELECT_LEX::update_used_tables after merging mergeable views and
derived tables into the main query. The leaf tables of resulting
query may change their bitmap numbers after this merge. That's why
the not_null_tables_cache bitmaps must be updated. Due to the bug
mentioned above the result of the re-evaluation of the
not_null_tables_cache turned out to be incorrect in some cases.
This could trigger an invalid conversion of outer joins into
inner joins leading to invalid query result sets.
Also removed an implicit conversion from int to bool in the function
SELECT_LEX::update_used_tables.
The value of THD::used tables should be re-evaluated after merges
of views and derived tables into the main query.
Now it's done in the function SELECT_LEX::update_used_tables.
The re-evaluation of the 'used_table' bitmaps for the items
in HAVING, GROUP BY and ORDER BY clauses has been added as well.
The bug was caused by an incorrect code of the function
Item_direct_view_ref::replace_equal_field introduced in the
patch for bugs 717577, 724942. The function erroneously
returned the wrapped field instead of the Item_direct_view_ref
object itself in the cases when no replacement happened.
The bug masked two other minor bugs that could result in not
quite correct output of the EXPLAIN command for some queries.
They were fixed in the patch as well.
The offending query returns a wrong result set because the optimizer
erroneously eliminated the where condition evaluated it to TRUE.
The cause of this wrong transformation was that the flag maybe_null
for an inner table of the outer join was not set to TRUE after the
table had replaced the wrapping view.
Now the function SELECT_LEX::update_used_tables resets the value
of the maybe_null flag for each leaf table of the query after all
merges of views have been done.
The function generate_derived_keys_for_table incorrectly handled
the cases when a materialized view or derived table could be accessed
by different keys on the same fields if these keys depended on the
same tables.
The function generate_derived_keys_for_table should set the value of
the number of keys for the derived table to 0 before it starts
generating key definitions for the table. It's important as the
function can be called twice by the optimizer for a derived table
if the query contains a subquery to which the IN-EXIST transformation
is applicable.
Fixed a valgrind complain.
If the expression for a derived table contained a clause LIMIT 0
SELECT from such derived table incorrectly returned a non-empty set.
Fixed by ensuring JOIN::do_send_rows to be updated after the call
of st_select_lex_unit::set_limit that sets the value of
JOIN::unit->select_limit_cnt.
Due to this bug in the function generate_derived_keys_for_table some
key definitions to access materialized derived tables or materialized
views were constructed with invalid info for their key parts.
This could make the server crash when it optimized queries using
materialized derived tables or materialized views.
Changed the code that processing of multi-updates and multi-deletes
with multitable views at the prepare stage.
A proper solution would be: never to perform any transformations of views
before and at the prepare stage. Yet it would require re-engineering
of the code that checks privileges and updatability of views.
Ultimately this re-engineering has to be done to provide a clean solution
for INSERT/UPDATE/DELETE statements that use views.
Fixed a valgrind problem in the function TABLE::use_index.
The function generate_derived_keys did not take into account the fact
that the last element in the array of keyuses could be just a barrier
element. In some cases it could lead to a crash of the server.
Also fixed a couple of other bugs in generate_derived_keys: the inner
loop in the body of if this function did not change the cycle variables
properly.
Resolved all conflicts, bad merges and fixed a few minor bugs in the code.
Commented out the queries from multi_update, view, subselect_sj, func_str,
derived_view, view_grant that failed either with crashes in ps-protocol or
with wrong results.
The failures are clear indications of some bugs in the code and these bugs
are to be fixed.
