diff options
author | kroki/tomash@moonlight.intranet <> | 2006-09-27 23:11:45 +0400 |
---|---|---|
committer | kroki/tomash@moonlight.intranet <> | 2006-09-27 23:11:45 +0400 |
commit | 0bdc597b521ba25305d01fa7610710d6f4a25d9c (patch) | |
tree | 7fb7f207eab73f6ba477df3c24f21e3da49e4669 /sql/item.cc | |
parent | bddfef1e360e8c511d801e084ea6a1b466f5dd90 (diff) | |
download | mariadb-git-0bdc597b521ba25305d01fa7610710d6f4a25d9c.tar.gz |
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().
Diffstat (limited to 'sql/item.cc')
-rw-r--r-- | sql/item.cc | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/sql/item.cc b/sql/item.cc index 34e5e2da165..7a4770731ea 100644 --- a/sql/item.cc +++ b/sql/item.cc @@ -3744,6 +3744,7 @@ void Item_field::cleanup() I.e. we can drop 'field'. */ field= result_field= 0; + null_value= FALSE; DBUG_VOID_RETURN; } |