A user that is granted a role must supply that role in their login credentials in order to exercise the associated privileges. Any other privileges granted to the user directly are not affected by their login with the role. Logging in with multiple roles simultaneously is not supported.

    In this section the tasks of creating and dropping roles are discussed.

    Used forCreating a new ROLE object

    Available inDSQL, ESQL

    Syntax

    Table 13.4.1.1 CREATE ROLE Statement Parameter

    The statement CREATE ROLE creates a new role object, to which one or more privileges can be granted subsequently. The name of a role must be unique among the names of roles in the current database.

    Warning

    It is advisable to make the name of a role unique among usernames as well. The system will not prevent the creation of a role whose name clashes with an existing username but, if it happens, the user will be unable to connect to the database.

    13.4.1.1 Who Can Create a Role

    The CREATE ROLE statement can be executed by:

    • Users with the CREATE ROLE privilege, with the following caveats

      • Setting system privileges also requires the system privilege CREATE_PRIVILEGED_ROLES

    13.4.1.2 CREATE ROLE Examples

    Creating a role named SELLERS

    1. CREATE ROLE SELLERS;

    Creating a role SELECT_ALL with the system privilege to select from any selectable object

    See also, Section 13.4.3, DROP ROLE, , REVOKE,

    Used forAltering a role

    Available inDSQL

    Syntax

    1. ALTER ROLE rolename
    2. { SET SYSTEM PRIVILEGES TO <sys_privileges>
    3. | DROP SYSTEM PRIVILEGES
    4. | {SET | DROP} AUTO ADMIN MAPPING }
    5. <sys_privileges> ::=

    Table 13.4.2.1 ALTER ROLE Statement Parameter

    ParameterDescription

    rolename

    Role name; specifying anything other than RDB$ADMIN will fail

    sys_privilege

    System privilege to grant

    ALTER ROLE can be used to grant or revoke system privileges from a role, or enable and disable the capability for Windows Administrators to assume administrator privileges automatically when logging in.

    This last capability can affect only one role: the system-generated role RDB$ADMIN that exists in every database of ODS 11.2 or higher.

    For details on auto admin mapping, see .

    It is not possible to selectively grant or revoke system privileges. Only the privileges listed in the clause will be available to the role after commit, and DROP SYSTEM PRIVILEGES will remove all system privileges from this role.

    13.4.2.1 Who Can Alter a Role

    The ALTER ROLE statement can be executed by:

    • Users with the ALTER ANY ROLE privilege, with the following caveats

      • Setting or dropping system privileges also requires the system privilege CREATE_PRIVILEGED_ROLES

      • Setting or dropping auto admin mapping also requires the system privilege CHANGE_MAPPING_RULES

    13.4.2.2 ALTER ROLE Examples

    Drop all system privileges from a role named SELECT_ALL

    Grant a role SELECT_ALL the system privilege to select from any selectable object

    1. ALTER ROLE SELECT_ALL
    2. SET SYSTEM PRIVILEGES TO SELECT_ANY_OBJECT_IN_DATABASE;

    See alsoSection 13.4.1, CREATE ROLE, , REVOKE,

    Used forDeleting a role

    Available inDSQL, ESQL

    Syntax

    The statement DROP ROLE deletes an existing role. It takes just a single argument, the name of the role. Once the role is deleted, the entire set of privileges is revoked from all users and objects that were granted the role.

    13.4.3.1 Who Can Drop a Role

    The DROP ROLE statement can be executed by:

    • The owner of the role

    • Users with the DROP ANY ROLE privilege

    13.4.3.2 DROP ROLE Examples

    Deleting the role SELLERS

      See also, GRANT,