A stored module resides in the database as an object. You can
    store modules and their procedures and functions with the CREATE
    MODULE statement.

    The authorization identifier, specified by using the
    AUTHORIZATION clause, enables Oracle Rdb to identify the user
    under whom the module executes.

    When you specify an authorization identifier in the definition of
    a stored module, that stored module is called a definer's rights
    module. This type of module enables any user who has EXECUTE
    privilege on the module to execute any of the module's routines
    without privileges on any of the underlying schema objects that
    the routine references. The routines execute under the rights
    identifier of the module definer, not the rights identifier of
    the person executing the routine. This ability to allow users
    access to schema objects through a call to a stored routine
    without having direct access to those schema objects is a key
    benefit of stored modules.

    In contrast, when you omit the AUTHORIZATION clause in the
    definition of a stored module, that stored module is called
    an invoker's rights module. In this type of module, users who
    have EXECUTE privilege on a particular module must also have
    privileges to all the underlying schema objects associated with
    any of the routines in this module that they want to execute.

    The following examples relate to stored modules and procedures.
    Authorization and CURRENT_USER are handled the same for both
    types of stored routines.

    Consider the following stored module definition, Module M1 with
    Procedure P1 and Authorization Brown. For example:

    CREATE MODULE M1
        LANGUAGE SQL
        AUTHORIZATION BROWN

        PROCEDURE P1 ();
        BEGIN
        TRACE CURRENT_USER;
        CALL P2 ();
        END;
    END MODULE;

    As you can see in the preceding example, P1 calls another stored
    procedure, P2. Procedure P2 is defined in Module M2 as the
    following example shows:

    CREATE MODULE M2
        LANGUAGE SQL
        -- no authorization
        PROCEDURE P2 ();
        BEGIN
        TRACE CURRENT_USER;
        CALL P3 ();
        END;
    END MODULE;

    Procedure P2 calls another procedure, P3, from Module M3, which
    is shown in the following example:

    CREATE MODULE M3
        LANGUAGE SQL
        -- no authorization
        PROCEDURE P3 ();
        BEGIN
        TRACE CURRENT_USER;
        .
        .
        .
        END;
    END MODULE;

    In each procedure you can trace the CURRENT_USER.

    Assume the following:

    o  Smith is granted the EXECUTE privilege on Module M1; but not
       on M2 or on M3.

    o  Brown is granted the EXECUTE privilege on Modules M1, M2, and
       M3.

    o  Jones is granted the EXECUTE privilege on Modules M1 and M2.

    When P1 is executed, CURRENT_USER always returns Brown as defined
    by the AUTHORIZATION clause in Module M1. When P2 or P3 are
    executed, the CURRENT_USER is either:

    o  Inherited from the calling routines AUTHORIZATION clause, or

    o  The CURRENT_USER of the calling routine if no authorization
       was specified

    When there is no AUTHORIZATION clause for the first calling
    routine, then CURRENT_USER is inherited from the SESSION_USER.