CREATE ROLE — Defines a role and the permissions associated with that role.
CREATE ROLE role-name [WITH permission [,...]]
The CREATE ROLE statement defines a named role that can be used to assign access rights to specific procedures and functions. When security is enabled in the deployment file, the permissions assigned in the CREATE ROLE and CREATE PROCEDURE statements specify which users can access which functions.
Use the CREATE PROCEDURE statement to assign permissions to named roles for accessing specific stored procedures. The CREATE ROLE statement lets you assign certain generic permissions. The following table describes the permissions that can be assigned the WITH clause.
|DEFAULTPROCREAD||Access to read-only default procedures (TABLE.select)|
|DEFAULTPROC||Access to all default procedures (TABLE.select, TABLE.insert, TABLE.delete, TABLE.update, and TABLE.upsert)||DEFAULTPROCREAD|
|SQLREAD||Access to read-only ad hoc SQL queries (SELECT)||DEFAULTPROCREAD|
|SQL||Access to all ad hoc SQL queries, including data definition language (DDL) statements and default procedures||SQLREAD, DEFAULTPROC|
|ALLPROC||Access to all user-defined stored procedures|
|ADMIN||Full access to all system procedures, all user-defined procedures, as well as default procedures and ad hoc SQL||ALLPROC, DEFAULTPROC, SQL|
Note: For backwards compatibility, the special permissions ADHOC and SYSPROC are still recognized. They are interpreted as synonyms for SQL and ADMIN, respectively.
The generic permissions are denied by default. So you must explicitly enable them for those roles that need them. For example, if users assigned to the "interactive" role need to run ad hoc queries, you must explicitly assign that permission in the CREATE ROLE statement:
CREATE ROLE interactive WITH sql;
Also note that the permissions are additive. So if a user is assigned to one role that allows access to defaultproc but not allproc, but that user also is assigned to another role that allows allproc, the user has both permissions.