1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

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.
This commit is contained in:
Alexander Nozdrin
2010-07-30 19:28:36 +04:00
parent 02a0787d8d
commit b2f8005094
30 changed files with 1385 additions and 344 deletions

View File

@ -153,8 +153,8 @@ private:
Representation of a SQL condition.
A SQL condition can be a completion condition (note, warning),
or an exception condition (error, not found).
@note This class is named MYSQL_ERROR instead of SQL_condition for historical reasons,
to facilitate merging code with previous releases.
@note This class is named MYSQL_ERROR instead of SQL_condition for
historical reasons, to facilitate merging code with previous releases.
*/
class MYSQL_ERROR : public Sql_alloc
{
@ -471,18 +471,6 @@ public:
ulong statement_warn_count() const { return m_statement_warn_count; }
/**
Reserve some space in the condition area.
This is a privileged operation, reserved for the RESIGNAL implementation,
as only the RESIGNAL statement is allowed to remove conditions from
the condition area.
For other statements, new conditions are not added to the condition
area once the condition area is full.
@param thd The current thread
@param count The number of slots to reserve
*/
void reserve_space(THD *thd, uint count);
/** Add a new condition to the current list. */
MYSQL_ERROR *push_warning(THD *thd,
uint sql_errno, const char* sqlstate,