The same change log entry lists additional changes. If they have been merged as well, they will also need the corresponding tests (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html):
Incompatible Change: MySQL now supports the GET DIAGNOSTICS statement. GET DIAGNOSTICS provides applications a standardized way to obtain information from the diagnostics area, such as whether the previous SQL statement produced an exception and what it was. For more information, see GET DIAGNOSTICS Syntax.
In addition several deficiencies in condition handler processing rules were corrected so that MySQL behavior is more like standard SQL:
Block scope is used in determining which handler to select. Previously, a stored program was treated as having a single scope for handler selection.
Condition precedence is more accurately resolved.
Diagnostics area clearing has changed. Bug #55843 caused handled conditions to be cleared from the diagnostics area before activating the handler. This made condition information unavailable within the handler. Now condition information is available to the handler, which can inspect it with the GET DIAGNOSTICS statement. The condition information is cleared when the handler exits, if it has not already been cleared during handler execution.
Previously, handlers were activated as soon as a condition occurred. Now they are not activated until the statement in which the condition occurred finishes execution, at which point the most appropriate handler is chosen. This can make a difference for statements that raise multiple conditions, if a condition raised later during statement execution has higher precedence than an earlier condition and there are handlers in the same scope for both conditions. Previously, the handler for the first condition raised would be chosen, even if it had a lower precedence than other handlers. Now the handler for the condition with highest precedence is chosen, even if it is not the first condition raised by the statement.
Issues that caused server crashes resulting from incorrect handler call stack processing were fixed.
The work just described involved several condition-handler bug fixes:
The RETURN statement did not clear the diagnostics area as it should have. Now the diagnostics area is cleared before executing RETURN. This prevents a condition in a nested function call from incorrectly propagating to an outer scope. It also means there is no way to return an SQL warning from a stored function. This change is not backward compatible, but the resulting behavior is more like standard SQL.
When an SQL HANDLER was activated, the handled condition was immediately removed from the diagnostics area. Consequently, any SQL diagnostic statement executed in the handler was unable to examine the condition that triggered the handler.
If multiple handlers existed at the same level within a stored program, the wrong one could be chosen.
If an error occurred in a context where different handlers were present at different levels of nesting, an outer handler could be chosen rather than the innermost one.
For more information, see Scope Rules for Handlers. (Bug #12951117, Bug #38806, Bug #11749343, Bug #55852, Bug #11763171, Bug #61392, Bug #12652873, Bug #11660, Bug #11745196)
Bug
Major
MDEV-4786 merge 10.0-monty → 10.0
The same change log entry lists additional changes. If they have been merged as well, they will also need the corresponding tests (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html):
Incompatible Change: MySQL now supports the GET DIAGNOSTICS statement. GET DIAGNOSTICS provides applications a standardized way to obtain information from the diagnostics area, such as whether the previous SQL statement produced an exception and what it was. For more information, see GET DIAGNOSTICS Syntax.
In addition several deficiencies in condition handler processing rules were corrected so that MySQL behavior is more like standard SQL:
Block scope is used in determining which handler to select. Previously, a stored program was treated as having a single scope for handler selection.
Condition precedence is more accurately resolved.
Diagnostics area clearing has changed. Bug #55843 caused handled conditions to be cleared from the diagnostics area before activating the handler. This made condition information unavailable within the handler. Now condition information is available to the handler, which can inspect it with the GET DIAGNOSTICS statement. The condition information is cleared when the handler exits, if it has not already been cleared during handler execution.
Previously, handlers were activated as soon as a condition occurred. Now they are not activated until the statement in which the condition occurred finishes execution, at which point the most appropriate handler is chosen. This can make a difference for statements that raise multiple conditions, if a condition raised later during statement execution has higher precedence than an earlier condition and there are handlers in the same scope for both conditions. Previously, the handler for the first condition raised would be chosen, even if it had a lower precedence than other handlers. Now the handler for the condition with highest precedence is chosen, even if it is not the first condition raised by the statement.
Issues that caused server crashes resulting from incorrect handler call stack processing were fixed.
The work just described involved several condition-handler bug fixes:
The RETURN statement did not clear the diagnostics area as it should have. Now the diagnostics area is cleared before executing RETURN. This prevents a condition in a nested function call from incorrectly propagating to an outer scope. It also means there is no way to return an SQL warning from a stored function. This change is not backward compatible, but the resulting behavior is more like standard SQL.
When an SQL HANDLER was activated, the handled condition was immediately removed from the diagnostics area. Consequently, any SQL diagnostic statement executed in the handler was unable to examine the condition that triggered the handler.
If multiple handlers existed at the same level within a stored program, the wrong one could be chosen.
If an error occurred in a context where different handlers were present at different levels of nesting, an outer handler could be chosen rather than the innermost one.
For more information, see Scope Rules for Handlers. (Bug #12951117, Bug #38806, Bug #11749343, Bug #55852, Bug #11763171, Bug #61392, Bug #12652873, Bug #11660, Bug #11745196)