Commit 265e833f authored by Sergei Golubchik's avatar Sergei Golubchik

revert 415faa12

that was mistakenly merged from mysql-5.5.47
parent c19972fc
......@@ -1748,27 +1748,6 @@ Item_in_subselect::single_value_transformer(JOIN *join)
runtime created Ref item which is deleted at the end
of the statement. Thus one of 'substitution' arguments
can be broken in case of PS.
@todo
Why do we use real_item()/substitutional_item() instead of the plain
left_expr?
Because left_expr might be a rollbackable item, and we fail to properly
rollback all copies of left_expr at end of execution, so we want to
avoid creating copies of left_expr as much as possible, so we use
real_item() instead.
Doing a proper rollback is difficult: the change was registered for the
original item which was the left argument of IN. Then this item was
copied to left_expr, which is copied below to substitution->args[0]. To
do a proper rollback, we would have to restore the content
of both copies as well as the original item. There might be more copies,
if AND items have been constructed.
The same applies to the right expression.
However, using real_item()/substitutional_item() brings its own
problems: for example, we lose information that the item is an outer
reference; the item can thus wrongly be considered for a Keyuse (causing
bug#17766653).
When WL#6570 removes the "rolling back" system, all
real_item()/substitutional_item() in this file should be removed.
*/
substitution= func->create(left_expr, where_item);
have_to_be_excluded= 1;
......@@ -2055,9 +2034,6 @@ Item_in_subselect::create_single_in_to_exists_cond(JOIN *join,
}
else
{
/*
Grep for "WL#6570" to see the relevant comment about real_item.
*/
Item *item= (Item*) select_lex->item_list.head()->real_item();
if (select_lex->table_list.elements)
......
......@@ -4114,17 +4114,6 @@ add_key_field(JOIN *join,
Field *field, bool eq_func, Item **value, uint num_values,
table_map usable_tables, SARGABLE_PARAM **sargables)
{
if (field->table->reginfo.join_tab == NULL)
{
/*
Due to a bug in IN-to-EXISTS (grep for real_item() in item_subselect.cc
for more info), an index over a field from an outer query might be
considered here, which is incorrect. Their query has been fully
optimized already so their reginfo.join_tab is NULL and we reject them.
*/
return;
}
uint optimize= 0;
if (eq_func &&
((join->is_allowed_hash_join_access() &&
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment