MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:kroki Date:September 27 2006 7:11pm
Subject:bk commit into 5.0 tree (kroki:1.2257) BUG#21081
View as plain text  
Below is the list of changes that have just been committed into a local
5.0 repository of tomash. When tomash 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@stripped, 2006-09-27 23:11:45+04:00, kroki@stripped +3 -0
  BUG#21081: SELECT inside stored procedure returns wrong results
  
  Re-execution of a parametrized prepared statement or a stored routine
  with a SELECT that use LEFT JOIN with second table having only one row
  could yield incorrect result.
  
  The problem appeared only for left joins with second table having only
  one row (aka const table) and equation conditions in ON or WHERE clauses
  that depend on the argument passed.  Once the condition was false for
  second const table, a NULL row was created for it, and any field involved
  got NULL-value flag, which then was never reset.
  
  The cause of the problem was that Item_field::null_value could be set
  without being reset for re-execution.  The solution is to reset
  Item_field::null_value in Item_field::cleanup().

  mysql-test/r/ps.result@stripped, 2006-09-27 23:11:42+04:00, kroki@stripped +21 -0
    Add result for bug#21081: SELECT inside stored procedure returns wrong
    results.

  mysql-test/t/ps.test@stripped, 2006-09-27 23:11:42+04:00, kroki@stripped +27 -0
    Add test case for bug#21081: SELECT inside stored procedure returns wrong
    results.

  sql/item.cc@stripped, 2006-09-27 23:11:42+04:00, kroki@stripped +1 -0
    Reset Item_field::null_value flag for re-execution.

# 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:	kroki
# Host:	moonlight.intranet
# Root:	/home/tomash/src/mysql_ab/mysql-5.0-bug21081

--- 1.233/sql/item.cc	2006-09-27 23:11:51 +04:00
+++ 1.234/sql/item.cc	2006-09-27 23:11:51 +04:00
@@ -3744,6 +3744,7 @@ void Item_field::cleanup()
     I.e. we can drop 'field'.
    */
   field= result_field= 0;
+  null_value= FALSE;
   DBUG_VOID_RETURN;
 }
 

--- 1.72/mysql-test/r/ps.result	2006-09-27 23:11:51 +04:00
+++ 1.73/mysql-test/r/ps.result	2006-09-27 23:11:51 +04:00
@@ -1311,4 +1311,25 @@ EXECUTE stmt USING @a;
 i	j	i	i	j
 DEALLOCATE PREPARE stmt;
 DROP TABLE IF EXISTS t1, t2, t3;
+DROP TABLE IF EXISTS t1, t2;
+CREATE TABLE t1 (i INT KEY);
+CREATE TABLE t2 (i INT);
+INSERT INTO t1 VALUES (1), (2);
+INSERT INTO t2 VALUES (1);
+PREPARE stmt FROM "SELECT t2.i FROM t1 LEFT JOIN t2 ON t2.i = t1.i
+                   WHERE t1.i = ?";
+SET @arg= 1;
+EXECUTE stmt USING @arg;
+i
+1
+SET @arg= 2;
+EXECUTE stmt USING @arg;
+i
+NULL
+SET @arg= 1;
+EXECUTE stmt USING @arg;
+i
+1
+DEALLOCATE PREPARE stmt;
+DROP TABLE t1, t2;
 End of 5.0 tests.

--- 1.69/mysql-test/t/ps.test	2006-09-27 23:11:51 +04:00
+++ 1.70/mysql-test/t/ps.test	2006-09-27 23:11:51 +04:00
@@ -1358,4 +1358,31 @@ DEALLOCATE PREPARE stmt;
 DROP TABLE IF EXISTS t1, t2, t3;
 
 
+#
+# BUG#21081: SELECT inside stored procedure returns wrong results
+#
+--disable_warnings
+DROP TABLE IF EXISTS t1, t2;
+--enable_warnings
+
+CREATE TABLE t1 (i INT KEY);
+CREATE TABLE t2 (i INT);
+
+INSERT INTO t1 VALUES (1), (2);
+INSERT INTO t2 VALUES (1);
+
+PREPARE stmt FROM "SELECT t2.i FROM t1 LEFT JOIN t2 ON t2.i = t1.i
+                   WHERE t1.i = ?";
+
+SET @arg= 1;
+EXECUTE stmt USING @arg;
+SET @arg= 2;
+EXECUTE stmt USING @arg;
+SET @arg= 1;
+EXECUTE stmt USING @arg;
+
+DEALLOCATE PREPARE stmt;
+DROP TABLE t1, t2;
+
+
 --echo End of 5.0 tests.
Thread
bk commit into 5.0 tree (kroki:1.2257) BUG#21081kroki27 Sep