A fix and a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?))

gives wrong results". Implement previously missing 
Item_row::cleanup. The bug is not repeatable in 5.0, probably 
due to a coincidence: the problem is present in 5.0 as well.


mysql-test/r/ps.result:
  Update the result file (Bug#16248)
mysql-test/t/ps.test:
  Add a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives 
  wrong results"
sql/item_row.cc:
  Implement Item_row::cleanup(): we should reset used_tables_cache
  before reexecution of a prepared statement. In case ROW
  arguments contain a placeholder, used_tables_cache has PARAM_TABLE
  bit set in statement prepare. As a result, when executing a statement,
  the condition push down algorithm (make_cond_for_table) would think
  that the WHERE clause belongs to the non-existent PARAM_TABLE and
  wouldn't attach the WHERE clause to any of the real tables, 
  effectively optimizing the clause away.
sql/item_row.h:
  Remove a never used member 'array_holder'. Add declaration for
  Item_row::cleanup.

1 files changed, 20 insertions, 0 deletions

diff --git a/mysql-test/r/ps.result b/mysql-test/r/ps.result
index e94c2952893..3f0b9e4fa8b 100644
--- a/mysql-test/r/ps.result
+++ b/mysql-test/r/ps.result
@@ -747,3 +747,23 @@ length(a)
 10
 drop table t1;
 deallocate prepare stmt;
+create table t1 (col1 integer, col2 integer);
+insert into t1 values(100,100),(101,101),(102,102),(103,103);
+prepare stmt from 'select col1, col2 from t1 where (col1, col2) in ((?,?))';
+set @a=100, @b=100;
+execute stmt using @a,@b;
+col1	col2
+100	100
+set @a=101, @b=101;
+execute stmt using @a,@b;
+col1	col2
+101	101
+set @a=102, @b=102;
+execute stmt using @a,@b;
+col1	col2
+102	102
+set @a=102, @b=103;
+execute stmt using @a,@b;
+col1	col2
+deallocate prepare stmt;
+drop table t1;