A user that is granted a role must supply that role in his login credentials in order to exercise the associated privileges. Any other privileges granted to the user are not affected by his 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.

    5.15.1. CREATE ROLE

    Used for

    Creating a new ROLE object

    Available in

    DSQL, ESQL

    Syntax

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

    Any user connected to the database can create a role. The user that creates a role becomes its owner.

    Example

    Creating a role named SELLERS:

    See also

    DROP ROLE, , REVOKE

    5.15.2. ALTER ROLE

    has no place in the create-alter-drop paradigm for database objects since a role has no attributes that can be modified. Its actual effect is to alter an attribute of the database: Firebird uses it to enable and disable the capability for Windows Adminstrators to assume administrator privileges automatically when logging in.

    This procedure can affect only one role: the system-generated role RDB$ADMIN that exists in every database of ODS 11.2 or higher. Several factors are involved in enabling this feature.

    For details, see in the Security chapter.

    5.15.3. DROP ROLE

    Deleting a role

    Available in

    DSQL, 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.

    A role can be deleted by its owner or by an .

    Example

    Deleting the role SELLERS:

    See also