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#21081 | kroki | 27 Sep |