From b17a4350696c646e4bc6154a27eeddf363cd39c7 Mon Sep 17 00:00:00 2001 From: Sergei Petrunia Date: Tue, 9 Feb 2016 02:31:47 +0300 Subject: MDEV-6859: scalar subqueries in a comparison produced unexpected result When one evaluates row-based comparison like (X, Y) = (A,B), one should first call bring_value() for the Item that returns row value. If you don't do that and just attempt to read values of X and Y, you get stale values. Semi-join/Materialization can take a row-based comparison apart and make ref access from it. In that case, we need to call bring_value() to get the index lookup components. --- sql/sql_select.cc | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'sql') diff --git a/sql/sql_select.cc b/sql/sql_select.cc index f43f506692c..a9b86b5e76b 100644 --- a/sql/sql_select.cc +++ b/sql/sql_select.cc @@ -17580,7 +17580,18 @@ int join_read_key2(THD *thd, JOIN_TAB *tab, TABLE *table, TABLE_REF *table_ref) } } + /* + The following is needed when one makes ref (or eq_ref) access from row + comparisons: one must call row->bring_value() to get the new values. + */ + if (tab && tab->bush_children) + { + TABLE_LIST *emb_sj_nest= tab->bush_children->start->emb_sj_nest; + emb_sj_nest->sj_subq_pred->left_expr->bring_value(); + } + /* TODO: Why don't we do "Late NULLs Filtering" here? */ + if (cmp_buffer_with_ref(thd, table, table_ref) || (table->status & (STATUS_GARBAGE | STATUS_NO_PARENT | STATUS_NULL_ROW))) { -- cgit v1.2.1