Bug #23032 Handlers declared in a SP do not handle warnings generated in sub-SP
Submitted: 5 Oct 2006 23:00 Modified: 6 Aug 2010 10:44
Reporter: Harrison Fisk Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Stored Routines Severity:S3 (Non-critical)
Version:5.0.24a OS:Any
Assigned to: Alexander Nozdrin CPU Architecture:Any

[5 Oct 2006 23:00] Harrison Fisk 
Description:
If you have a stored procedure which has a handler for a warning condition, and this stored procedure invokes another stored procedure which causes that warning, the warning is not handled by the outer stored procedure handler.

If a warning is generated directly by the stored procedure it is handled.  Also errors will be propagated to the outer handler, but warnings are not propagated back to the invoking SP.

Bug#21801 also indicates problems with warnings and handlers, but appears to be a different issue.

How to repeat:
Test case illustrating the problem:

=====

SET @old_sql_mode = @@sql_mode;
DROP TABLE IF EXISTS t1;
DROP PROCEDURE IF EXISTS p1;
DROP PROCEDURE IF EXISTS p2;

CREATE TABLE t1 (col CHAR(3));

SET sql_mode = '';
delimiter //

CREATE PROCEDURE p1 () INSERT INTO t1 VALUES ('aaaaa')//

CREATE PROCEDURE p2 () 
BEGIN
DECLARE CONTINUE HANDLER FOR 1265 BEGIN END;
CALL p1();
END;
//
delimiter ;

-- produces warning
CALL p1();

-- produces warning, but shouldn't?
CALL p2();

DROP PROCEDURE p2;
DROP PROCEDURE p1;
DROP TABLE t1;

SET @@sql_mode = @old_sql_mode;

======

A test case showing that errors are propagated properly:

======

SET @old_sql_mode = @@sql_mode;
DROP TABLE IF EXISTS t1;
DROP PROCEDURE IF EXISTS p1;
DROP PROCEDURE IF EXISTS p2;

CREATE TABLE t1 (col CHAR(3));

SET sql_mode = 'strict_all_tables';
delimiter //

CREATE PROCEDURE p1 () INSERT INTO t1 VALUES ('aaaaa')//

CREATE PROCEDURE p2 () 
BEGIN
DECLARE CONTINUE HANDLER FOR 1406 BEGIN END;
CALL p1();
END;
//
delimiter ;

-- produces error
CALL p1();

-- produces no error
CALL p2();

DROP PROCEDURE p2;
DROP PROCEDURE p1;
DROP TABLE t1;

SET @@sql_mode = @old_sql_mode;

Suggested fix:
Send the warnings back to the original invoking SP to handle if there is no local handler.

As a work around, you need to declare all warning handlers local to each SP.
[7 Apr 2008 17:30] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45010

ChangeSet@1.2622, 2008-04-07 14:29:44-03:00, davi@mysql.com +22 -0
  Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP
  
  The problem is that warnings generated by a statement executed
  inside a stored procedure should only invoke handlers in the
  calling context. Also, the diagnostics and condition areas must
  be cleaned before the execution of stored procedure statements.
  
  The solution is to prepare the enviorement before the execution
  of procedure statements by clearing the diagnostics area (and
  thus condition area). Also handlers now are only called for
  handling warnings generated in the calling context of the executed
  statement.
[15 Apr 2008 17:25] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45444

ChangeSet@1.2643, 2008-04-15 14:25:01-03:00, davi@mysql.com +19 -0
  Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP
  
  The problem is that warnings generated by a statement executed
  inside a stored procedure should only invoke handlers in the
  calling context. Also, the diagnostics and condition areas must
  be cleaned before the execution of stored procedure statements.
    
  The solution is to prepare the enviorement before the execution
  of procedure statements by clearing the diagnostics area (and
  thus condition area). Also handlers now are only called for
  handling warnings generated in the calling context of the executed
  statement.
[18 Apr 2008 4:04] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45587

ChangeSet@1.2618, 2008-04-18 01:03:47-03:00, davi@mysql.com +18 -0
  Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP
  
  The problem is that warnings generated by a statement executed
  inside a stored procedure should only invoke handlers in the
  calling context, unless the warning is generated by the last
  statement of the stored procedure.
  
  The solution is to prepare the environment before the execution
  of procedure statements and tightly control if warning were generated
  during the execution of the statement. Also handlers now are only
  called for handling warnings generated in the calling context of the
  executed statement, unless it's the last statement of the stored
  procedure.
  
  Now statements executed inside stored procedure fallow the same
  rules as non-sp statements with respect to effects on the message
  list (refer to SHOW WARNINGS manual entry for more details).
  
  Bug#36185: Incorrect precedence for warning and exception handlers
  
  The problem is that MySQL calls the handler for the first signaled
  condition during the execution of a stored procedure statement,
  meaning that if a warning is signaled first, it will search for a
  handler at that point and if a handler is found it won't look further
  for other handlers even if new warning/exception conditions occur.
  
  The solution is to look for handler only at the end of the execution
  of a statement. At the end, it looks first for error and not found
  conditions. If the execution completed successfully (no errors)
  but warnings were generated, it searches for a single handler in a
  first generated first served schema.
[18 Apr 2008 13:20] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45606

ChangeSet@1.2618, 2008-04-18 08:39:09-03:00, davi@mysql.com +18 -0
  Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP
  
  The problem is that warnings generated by a statement executed
  inside a stored procedure should only invoke handlers in the
  calling context, unless the warning is generated by the last
  statement of the stored procedure.
  
  The solution is to prepare the environment before the execution
  of procedure statements and tightly control if warning were generated
  during the execution of the statement. Also handlers now are only
  called for handling warnings generated in the calling context of the
  executed statement, unless it's the last statement of the stored
  procedure.
  
  Now statements executed inside stored procedure fallow the same
  rules as non-sp statements with respect to effects on the message
  list (refer to SHOW WARNINGS manual entry for more details).
  
  Bug#36185: Incorrect precedence for warning and exception handlers
  
  The problem is that MySQL calls the handler for the first signaled
  condition during the execution of a stored procedure statement,
  meaning that if a warning is signaled first, it will search for a
  handler at that point and if a handler is found it won't look further
  for other handlers even if new warning/exception conditions occur.
  
  The solution is to look for handler only at the end of the execution
  of a statement. At the end, it looks first for error and not found
  conditions. If the execution completed successfully (no errors)
  but warnings were generated, it searches for a single handler in a
  first generated first served schema.
[23 Apr 2008 22:53] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/45925

ChangeSet@1.2628, 2008-04-23 19:52:42-03:00, davi@mysql.com +22 -0
  Bug#23032: Handlers declared in a SP do not handle warnings generated in sub-SP
  
  The problem is that warnings generated by a statement executed
  inside a stored procedure should only invoke handlers in the
  calling context, unless the warning is generated by the last
  statement of the stored procedure.
  
  The solution is to prepare the environment before the execution
  of procedure statements and tightly control if warning were generated
  during the execution of the statement. Also handlers now are only
  called for handling warnings generated in the calling context of the
  executed statement, unless it's the last statement of the stored
  procedure.
  
  This is a incompatible change, now statements executed inside stored
  procedure fallow the same rules as non-sp statements with respect to
  effects on the message list (refer to SHOW WARNINGS manual entry for
  more details).
  
  Bug#36185: Incorrect precedence for warning and exception handlers
  
  The problem is that MySQL calls the handler for the first signaled
  condition during the execution of a stored procedure statement,
  meaning that if a warning is signaled first, it will search for a
  handler at that point and if a handler is found it won't look further
  for other handlers even if new warning/exception conditions occur.
  
  The solution is to look for handler only at the end of the execution
  of a statement. At the end, it looks first for error and not found
  conditions. If the execution completed successfully (no errors)
  but warnings were generated, it searches for a single handler in a
  first generated first served schema.
[27 Apr 2008 7:16] Sveta Smirnova 
Bug #36348 was marked as duplicate of this one.
[21 Jul 2010 14:16] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114045

3133 Alexander Nozdrin	2010-07-21
      Preliminary patch for Bug#23032 (Handlers declared in a SP
      do not handle warnings generated in sub-SP).
[29 Jul 2010 22:09] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114685

3158 Alexander Nozdrin	2010-07-30
      This patch fixes the following bugs:
        - Bug#5889: Exit handler for a warning doesn't hide the warning in
          trigger
        - Bug#9857: Stored procedures: handler for sqlwarning ignored
        - Bug#23032: Handlers declared in a SP do not handle warnings generated
          in sub-SP
        - Bug#36185: Incorrect precedence for warning and exception handlers
      
      The problem was in the way warnings/errors during stored routine execution
      were handled. Prior to this patch the logic was as follows:
        - when a warning/an error happens: if we're executing a stored routine,
          and there is a handler for that warning/error, remember the handler,
          ignore the warning/error and continue execution.
        - after a stored routine instruction is executed: check for a remembered
          handler and activate one (if any).
      
      This logic caused several problems:
      
        - if one instruction generates several warnings (errors) it's impossible
          to choose the right handler -- a handler for the first generated
          condition was chosen and remembered for activation.
      
        - mess with handling conditions in scopes different from the current one.
      
        - not putting generated warnings/errors into Warning Info (Diagnostic
          Area) is against The Standard.
      
      The patch changes the logic as follows:
        - Diagnostic Area is cleared on the beginning of each statement that
          either is able to generate warnings, or is able to work with tables.
      
        - at the end of a stored routine instruction, Diagnostic Area is left
          intact.
      
        - Diagnostic Area is checked after each stored routine instruction. If
          an instruction generates several condition, it's now possible to take a
          look at all of them and determine an appropriate handler.
[30 Jul 2010 11:36] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114720

3158 Alexander Nozdrin	2010-07-30
      This patch fixes the following bugs:
        - Bug#5889: Exit handler for a warning doesn't hide the warning in
          trigger
        - Bug#9857: Stored procedures: handler for sqlwarning ignored
        - Bug#23032: Handlers declared in a SP do not handle warnings generated
          in sub-SP
        - Bug#36185: Incorrect precedence for warning and exception handlers
      
      The problem was in the way warnings/errors during stored routine execution
      were handled. Prior to this patch the logic was as follows:
      
        - when a warning/an error happens: if we're executing a stored routine,
          and there is a handler for that warning/error, remember the handler,
          ignore the warning/error and continue execution.
      
        - after a stored routine instruction is executed: check for a remembered
          handler and activate one (if any).
      
      This logic caused several problems:
      
        - if one instruction generates several warnings (errors) it's impossible
          to choose the right handler -- a handler for the first generated
          condition was chosen and remembered for activation.
      
        - mess with handling conditions in scopes different from the current one.
      
        - not putting generated warnings/errors into Warning Info (Diagnostic
          Area) is against The Standard.
      
      The patch changes the logic as follows:
      
        - Diagnostic Area is cleared on the beginning of each statement that
          either is able to generate warnings, or is able to work with tables.
      
        - at the end of a stored routine instruction, Diagnostic Area is left
          intact.
      
        - Diagnostic Area is checked after each stored routine instruction. If
          an instruction generates several condition, it's now possible to take a
          look at all of them and determine an appropriate handler.
     @ mysql-test/r/signal.result
        Update result file:
          1. handled conditions are not cleared any more;
          2. reflect changes in signal.test
     @ mysql-test/r/signal_demo3.result
        Update result file: handled conditions are not cleared any more.
        Due to playing with max_error_count, resulting warning lists
        have changed.
     @ mysql-test/r/sp-big.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp-bugs.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp-code.result
        Update result file:
          1. handled conditions are not cleared any more.
          2. add result for a new test case in sp-code.test.
     @ mysql-test/r/sp-error.result
        Update result file:
          1. handled conditions are not cleared any more.
          2. add result for a new test case in sp-error.test.
     @ mysql-test/r/sp.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp_trans.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/strict.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/view.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/innodb_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/memory_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/myisam_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/storedproc.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_sp005.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_trig003.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/t/signal.test
        Make a test case more readable in the result file.
     @ mysql-test/t/sp-code.test
        Add a test case for Bug#23032 checking that
        No Data takes precedence on Warning.
     @ mysql-test/t/sp-error.test
        Adding test cases for:
          - Bug#23032
          - Bug#36185
          - Bug#5889
          - Bug#9857
     @ mysql-test/t/sp.test
        Fixing test case to reflect behavioral changes made by the patch.
     @ sql/sp_head.cc
        Reset the per-statement warning count before executing
        a stored procedure instruction.
        
        Move to a separate function code which checks the
        completion status of the executed statement and searches
        for a handler.
        
        Remove redundant code now that search for a handler is
        done after execution, errors are always pushed.
     @ sql/sp_pcontext.h
        Remove unused code.
     @ sql/sp_rcontext.cc
        - Polish sp_rcontext::find_handler(): use sp_rcontext::m_hfound instead
          of an extra local variable;
        
        - Remove sp_rcontext::handle_condition();
        
        - Introduce sp_rcontext::activate_handler(), which prepares
          previously found handler for execution.
        
        - Move sp_rcontext::enter_handler() code into activate_handler(),
          because enter_handler() is used only from there;
        
        - Cleanups;
        
        - Introduce DBUG_EXECUTE_IF() for a test case in sp-code.test
     @ sql/sp_rcontext.h
        - Remove unused code
        - Cleanups
     @ sql/sql_class.cc
        Merge THD::raise_condition_no_handler() into THD::raise_condition().
        After the patch raise_condition_no_handler() was called
        in raise_condition() only.
     @ sql/sql_class.h
        Remove raise_condition_no_handler().
     @ sql/sql_error.cc
        Remove Warning_info::reserve_space() -- handled conditions are not
        cleared any more, so there is no need for RESIGNAL to re-push them.
     @ sql/sql_error.h
        Remove Warning_info::reserve_space().
     @ sql/sql_signal.cc
        Handled conditions are not cleared any more,
        so there is no need for RESIGNAL to re-push them.
[30 Jul 2010 15:30] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/114769

3158 Alexander Nozdrin	2010-07-30
      Auto-merge from mysql-trunk-bugfixing.
      ******
      This patch fixes the following bugs:
        - Bug#5889: Exit handler for a warning doesn't hide the warning in
          trigger
        - Bug#9857: Stored procedures: handler for sqlwarning ignored
        - Bug#23032: Handlers declared in a SP do not handle warnings generated
          in sub-SP
        - Bug#36185: Incorrect precedence for warning and exception handlers
      
      The problem was in the way warnings/errors during stored routine execution
      were handled. Prior to this patch the logic was as follows:
      
        - when a warning/an error happens: if we're executing a stored routine,
          and there is a handler for that warning/error, remember the handler,
          ignore the warning/error and continue execution.
      
        - after a stored routine instruction is executed: check for a remembered
          handler and activate one (if any).
      
      This logic caused several problems:
      
        - if one instruction generates several warnings (errors) it's impossible
          to choose the right handler -- a handler for the first generated
          condition was chosen and remembered for activation.
      
        - mess with handling conditions in scopes different from the current one.
      
        - not putting generated warnings/errors into Warning Info (Diagnostic
          Area) is against The Standard.
      
      The patch changes the logic as follows:
      
        - Diagnostic Area is cleared on the beginning of each statement that
          either is able to generate warnings, or is able to work with tables.
      
        - at the end of a stored routine instruction, Diagnostic Area is left
          intact.
      
        - Diagnostic Area is checked after each stored routine instruction. If
          an instruction generates several condition, it's now possible to take a
          look at all of them and determine an appropriate handler.
     @ mysql-test/r/signal.result
        Update result file:
          1. handled conditions are not cleared any more;
          2. reflect changes in signal.test
     @ mysql-test/r/signal_demo3.result
        Update result file: handled conditions are not cleared any more.
        Due to playing with max_error_count, resulting warning lists
        have changed.
     @ mysql-test/r/sp-big.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp-bugs.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp-code.result
        Update result file:
          1. handled conditions are not cleared any more.
          2. add result for a new test case in sp-code.test.
     @ mysql-test/r/sp-error.result
        Update result file:
          1. handled conditions are not cleared any more.
          2. add result for a new test case in sp-error.test.
     @ mysql-test/r/sp.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/sp_trans.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/strict.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/r/view.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/innodb_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/memory_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/myisam_storedproc_02.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/funcs_1/r/storedproc.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_sp005.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/suite/rpl/r/rpl_row_trig003.result
        Update result file: handled conditions are not cleared any more.
     @ mysql-test/t/signal.test
        Make a test case more readable in the result file.
     @ mysql-test/t/sp-code.test
        Add a test case for Bug#23032 checking that
        No Data takes precedence on Warning.
     @ mysql-test/t/sp-error.test
        Adding test cases for:
          - Bug#23032
          - Bug#36185
          - Bug#5889
          - Bug#9857
     @ mysql-test/t/sp.test
        Fixing test case to reflect behavioral changes made by the patch.
     @ sql/sp_head.cc
        Reset the per-statement warning count before executing
        a stored procedure instruction.
        
        Move to a separate function code which checks the
        completion status of the executed statement and searches
        for a handler.
        
        Remove redundant code now that search for a handler is
        done after execution, errors are always pushed.
     @ sql/sp_pcontext.h
        Remove unused code.
     @ sql/sp_rcontext.cc
        - Polish sp_rcontext::find_handler(): use sp_rcontext::m_hfound instead
          of an extra local variable;
        
        - Remove sp_rcontext::handle_condition();
        
        - Introduce sp_rcontext::activate_handler(), which prepares
          previously found handler for execution.
        
        - Move sp_rcontext::enter_handler() code into activate_handler(),
          because enter_handler() is used only from there;
        
        - Cleanups;
        
        - Introduce DBUG_EXECUTE_IF() for a test case in sp-code.test
     @ sql/sp_rcontext.h
        - Remove unused code
        - Cleanups
     @ sql/sql_class.cc
        Merge THD::raise_condition_no_handler() into THD::raise_condition().
        After the patch raise_condition_no_handler() was called
        in raise_condition() only.
     @ sql/sql_class.h
        Remove raise_condition_no_handler().
     @ sql/sql_error.cc
        Remove Warning_info::reserve_space() -- handled conditions are not
        cleared any more, so there is no need for RESIGNAL to re-push them.
     @ sql/sql_error.h
        Remove Warning_info::reserve_space().
     @ sql/sql_signal.cc
        Handled conditions are not cleared any more,
        so there is no need for RESIGNAL to re-push them.
[4 Aug 2010 7:51] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:55] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:56] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:57] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:58] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 7:59] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 8:00] Bugs System 
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:alik@sun.com-20100731074942-o840woifuqioxxe4) (merge vers: 5.5.6-m3) (pib:18)
[4 Aug 2010 8:10] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:13] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:14] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:15] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:16] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:17] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:26] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 9:00] Bugs System 
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (merge vers: 5.6.99-m4) (pib:20)
[4 Aug 2010 9:05] Bugs System 
Pushed into mysql-next-mr (revid:alik@ibmvm-20100804081630-ntapn8bf9pko9vj3) (version source revid:alik@sun.com-20100731075120-qz9z8c25zum2wgmm) (pib:20)
[6 Aug 2010 10:44] Paul DuBois 
Noted in 5.5.6 changelog.

Handling of warnings and errors during stored program execution was
problematic: 

* If one statement generated several warnings or errors, only the
  handler for the first was activated, even if another might be ore
  appropriate.

* Warning or error information could be lost.
[2 Mar 2011 6:50] Patrick Wheeler 
This fix seems to have changed the way conditions handled in a function are handled by a procedure which invokes that function. Consider these test cases: temp_proc1 behaves as expected. temp_proc2 behaves differently in 5.5 than it did in 5.1. Shouldn't the function's continue handler isolate the condition from the calling procedure's handler?

delimiter $$

drop procedure if exists temp_proc1$$
create procedure         temp_proc1
  (
  )

begin

  declare V_First_Integer        int;
  declare V_Second_Integer       int;

  declare exit handler for not found
  select 'No data found - stop' as "Error";
  
  select 'This should work' as "Step 1";
  
  select 1
  into V_First_Integer
  from dual
  ;
  
  begin
  
    declare continue handler for not found
    select 'No data found - continue' as "Status";
    
    select 'This should fail' as "Step 2";
    
    select 2
    into V_Second_Integer
    from dual
    where 1=2
    ;
    
  end;
  
  select 'Did we get this far, though?' as "Progress Check";

end$$

drop function if exists temp_func$$
create function         temp_func
  (
  )
returns int

begin

  declare V_Return_Value             int default 2;
  declare V_Third_Integer            int;

  begin
  
    declare continue handler for not found begin end;
    
    select 3
    into V_Third_Integer
    from dual
    where 1=2
    ;
    
  end;
 
  return V_Return_Value;

end$$

drop procedure if exists temp_proc2$$
create procedure         temp_proc2
  (
  )

begin

  declare V_First_Integer        int;
  declare V_Second_Integer       int;

  declare exit handler for not found
  select 'No data found - stop' as "Error";
  
  select 'Shouldn''t this work? It fails - watch this:' as "Step 1";
  
  select 1
  ,      temp_func()
  into V_First_Integer
  ,    V_Second_Integer
  from dual
  ;
    
  select 'Did we get this far, though?' as "Progress Check";

end$$

delimiter ;