From: Date: March 28 2006 7:36pm
Subject: bk commit into 4.1 tree (konstantin:1.2480) BUG#16248
List-Archive: http://lists.mysql.com/commits/4248
X-Bug: 16248
Message-Id: <20060328173618.D45427AB4@dragonfly.local>

Below is the list of changes that have just been committed into a local
4.1 repository of kostja. When kostja does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet
  1.2480 06/03/28 21:36:11 konstantin@stripped +4 -0
  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 roblem is present in 5.0 as well. 

  sql/item_row.h
    1.17 06/03/28 21:36:06 konstantin@stripped +1 -2
    Remove a never used member 'array_holder'. Add declaration for
    Item_row::cleanup.

  sql/item_row.cc
    1.29 06/03/28 21:36:06 konstantin@stripped +15 -1
    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.

  mysql-test/t/ps.test
    1.49 06/03/28 21:36:06 konstantin@stripped +18 -0
    Add a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives 
    wrong results"

  mysql-test/r/ps.result
    1.48 06/03/28 21:36:06 konstantin@stripped +20 -0
    Update the result file (Bug#16248)

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	konstantin
# Host:	dragonfly.local
# Root:	/opt/local/work/mysql-4.1-16248

--- 1.28/sql/item_row.cc	2005-02-08 15:41:05 +03:00
+++ 1.29/sql/item_row.cc	2006-03-28 21:36:06 +04:00
@@ -26,7 +26,7 @@
 */
 
 Item_row::Item_row(List<Item> &arg):
-  Item(), used_tables_cache(0), array_holder(1), const_item_cache(1), with_null(0)
+  Item(), used_tables_cache(0), const_item_cache(1), with_null(0)
 {
 
   //TODO: think placing 2-3 component items in item (as it done for function)
@@ -82,6 +82,20 @@
   }
   fixed= 1;
   return 0;
+}
+
+
+void Item_row::cleanup()
+{
+  DBUG_ENTER("Item_row::cleanup");
+
+  Item::cleanup();
+  /* Reset to the original values */
+  used_tables_cache= 0;
+  const_item_cache= 1;
+  with_null= 0;
+
+  DBUG_VOID_RETURN;
 }
 
 

--- 1.16/sql/item_row.h	2004-10-08 19:13:06 +04:00
+++ 1.17/sql/item_row.h	2006-03-28 21:36:06 +04:00
@@ -19,7 +19,6 @@
   Item **items;
   table_map used_tables_cache;
   uint arg_count;
-  bool array_holder;
   bool const_item_cache;
   bool with_null;
 public:
@@ -29,7 +28,6 @@
     items(item->items),
     used_tables_cache(item->used_tables_cache),
     arg_count(item->arg_count),
-    array_holder(0), 
     const_item_cache(item->const_item_cache),
     with_null(0)
   {}
@@ -57,6 +55,7 @@
     return 0;
   };
   bool fix_fields(THD *thd, TABLE_LIST *tables, Item **ref);
+  void cleanup();
   void split_sum_func(THD *thd, Item **ref_pointer_array, List<Item> &fields);
   table_map used_tables() const { return used_tables_cache; };
   bool const_item() const { return const_item_cache; };

--- 1.47/mysql-test/r/ps.result	2006-02-23 23:41:06 +03:00
+++ 1.48/mysql-test/r/ps.result	2006-03-28 21:36:06 +04:00
@@ -747,3 +747,23 @@
 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;

--- 1.48/mysql-test/t/ps.test	2006-02-23 23:41:06 +03:00
+++ 1.49/mysql-test/t/ps.test	2006-03-28 21:36:06 +04:00
@@ -785,4 +785,22 @@
 drop table t1;
 deallocate prepare stmt;
 
+#
+# Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives wrong results":
+# check that ROW implementation is reexecution-friendly.
+#
+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;
+set @a=101, @b=101;
+execute stmt using @a,@b;
+set @a=102, @b=102;
+execute stmt using @a,@b;
+set @a=102, @b=103;
+execute stmt using @a,@b;
+deallocate prepare stmt;
+drop table t1;
+
 # End of 4.1 tests