diff options
author | unknown <malff/marcsql@weblab.(none)> | 2006-08-02 22:18:49 -0700 |
---|---|---|
committer | unknown <malff/marcsql@weblab.(none)> | 2006-08-02 22:18:49 -0700 |
commit | f748b69134c62cfd1767357b7f4adeb7e990ee2e (patch) | |
tree | 987c7b7c3125c669d39ab406692b81e733eea48c /sql/sp_rcontext.h | |
parent | d57c41b79d972012ae76fe0b36ee31b1e97989ef (diff) | |
download | mariadb-git-f748b69134c62cfd1767357b7f4adeb7e990ee2e.tar.gz |
Bug#8153 (Stored procedure with subquery and continue handler, wrong result)
Before this fix,
- a runtime error in a statement in a stored procedure with no error handlers
was properly detected (as expected)
- a runtime error in a statement with an error handler inherited from a non
local runtime context (i.e., proc a with a handler, calling proc b) was
properly detected (as expected)
- a runtime error in a statement with a *local* error handler was executed
as follows :
a) the statement would succeed, regardless of the error condition, (bug)
b) the error handler would be called (as expected).
The root cause is that functions like my_messqge_sql would "forget" to set
the thread flag thd->net.report_error to 1, because of the check involving
sp_rcontext::found_handler_here().
Failure to set this flag would cause, later in the call stack,
in Item_func::fix_fields() at line 190, the code to return FALSE and consider
that executing the statement was successful.
With this fix :
- error handling code, that was duplicated in different places in the code,
is now implemented in sp_rcontext::handle_error(),
- handle_error() correctly sets thd->net.report_error when a handler is
present, regardless of the handler location (local, or in the call stack).
A test case, bug8153_subselect, has been written to demonstrate the change
of behavior before and after the fix.
Another test case, bug8153_function_a, as also been writen.
This test has the same behavior before and after the fix.
This test has been written to demonstrate that the previous expected
result of procedure bug18787, was incorrect, since select no_such_function()
should fail and therefore not produce a result.
The incorrect result for bug18787 has the same root cause as Bug#8153,
and the expected result has been adjusted.
sql/mysqld.cc:
Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/sql_error.cc:
Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/protocol.cc:
Bug#8153, use sp_rcontext::handle_error() to handle errors.
sql/sp_rcontext.h:
Bug#8153, created helper sp_rcontext::handle_error() to handle errors.
sql/sp_rcontext.cc:
Bug#8153, created helper sp_rcontext::handle_error() to handle errors.
mysql-test/t/sp.test:
Bug#8153, added test cases.
mysql-test/r/sp.result:
Bug#8153, added test cases, fixed expected result of bug18787.
Diffstat (limited to 'sql/sp_rcontext.h')
-rw-r--r-- | sql/sp_rcontext.h | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/sql/sp_rcontext.h b/sql/sp_rcontext.h index 30521f6da84..5e03aa60d23 100644 --- a/sql/sp_rcontext.h +++ b/sql/sp_rcontext.h @@ -128,6 +128,12 @@ class sp_rcontext : public Sql_alloc bool find_handler(uint sql_errno,MYSQL_ERROR::enum_warning_level level); + // If there is an error handler for this error, handle it and return TRUE. + bool + handle_error(uint sql_errno, + MYSQL_ERROR::enum_warning_level level, + THD *thd); + // Returns handler type and sets *ip to location if one was found inline int found_handler(uint *ip, uint *fp) |