MySQL WL#5986: Stored programs: make SQL-handlers closer to the standard

revno: 3398.2.11

committer: Alexander Nozdrin <alexander.nozdrin@oracle.com>

branch nick: mysql-trunk-alik-38806.2

timestamp: Wed 2011-08-24 19:33:15 +0400

message:

  WL#5986: Stored programs: make SQL-handlers closer to the standard).

  Patch for the following bugs:

    - Bug#11763171: 55852 - Possibly inappropriate handler activation.

    - Bug#11749343: 38806 - Wrong scope for SQL HANDLERS in SP.

  The problem was that SQL-handler resolution was done in a hackish way, which

  has nothing do with the SQL Standard requirements.

  The following terms are used below:

    - "handler" is an alias for "SQL-handler";

    - "scope" is an alias for "parsing scope", which is in turn an alias for

      "BEGIN .. END block";

    - "parsing context" -- an instance of sp_pcontext class;

    - "runtime context" -- an instance of sp_rcontext class;

  SQL-handlers were resolved using stack of stored program calls (runtime context

  stack). Information about scopes is not preserved in the runtime context. Thus,

  there was no way to ensure proper SQL-handler resolution if there were more

  than one scope.

  In other words, user-visible problem was that SQL-handlers were not properly

  chosen if there were several BEGIN .. END blocks with SQL-handlers inside them.

  For more information about the standard way to resolve handlers, see WL#5986

  and the mentioned bugs.

  The general idea of the patch is to resolve handlers in runtime using the

  parsing context of the instruction that raised SQL-condition(s).

  Here are some background information and steps that describes the patch:

    - An SP instruction has a pointer to its parsing context. So, it's possible

      to get instruction's parsing context when instruction raised

      SQL-condition(s).

    - A method to find the right handler should be moved to sp_pcontext class.

      This method should firstly look through the handlers declared in the

      current parsing context, then call the parent parsing context.

    - When an appropriate SQL-handler is found, we need to find its entering IP

      (instruction pointer). I.e. we need to get the pointer to the first

      SP-instruction of that handler. This information is available only in the

      runtime context.

    - Runtime contexts may has pointers to data in parsing contexts, but not vice

      versa.

    - Thus, we need to establish a link between a handler in the parsing context,

      and that handler in the runtime context. That means, we need some

      identification of handlers.

    - Before this patch, there has been no class/object to store information about

      declared SQL-handler. SQL-handlers were represented by SQL-condition-values.

    - It is not possible to identify handlers by theis condition values, because

      there might be several handlers using the same condition value. It happens,

      when there is a named condition and a few handlers for that condition in

      different scopes.

    - This patch introduces sp_handler class, which has two attributes:

      - handler type (only EXIT and CONTINUE are now supported);

      - list of condition values, which are caugh by this handler;

    - The parsing context stores an array of sp_handler instances.

    - The runtime context has a map between a pointer to sp_handler-object, and

      its entering instruction pointer. That map is filled/refreshed by means of

      hpush/hpop instructions.

  Programming-wise, the following things have been changed:

    - sp_active_handler_t has been removed, sp_rcontext::m_in_handlers[]

      is now an array of uint's.

    - sp.test has been fixed because it contained tests for wrong

      behaviour.

    - new tests have been added to sp-error.test

    - a new variant of sp_pcontext::find_handler() has been introduced,

      which does all the job to find appropriate SQL-handler for the

      given SQL-condition in the current frame/scope.

    - "active" handlers (or handlers "in use") are no longer needed for

      handler resolution, because it was a hackish (and incorrect) attempt

      to implement stacked handler resolution. The scoped resolution rules

      guarantee that handlers will not be activated recursively.

  SP-code polishing/cleanup:

    - remove entering-instruction-pointer from sp_handler, use it in sp_pcontext

      to store handler definitions;

    - introduce private sp_rcontext::sp_handler_entry, which contains entering ip

      for a handler;

    - get rid of macros SP_HANDLER_xxx, replace them by

      sp_handler::enum_type enum;

    - a few other renames;