Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6061

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

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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;

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              svoj Sergey Vojtovich
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: