REVOKE revokes from . For the list of privileges that can be granted to and revoked from users and roles, see .
You can use REVOKE to directly revoke privileges from a role or user, or you can revoke membership to an existing role, which effectively revokes that role’s privileges.
The “ statement performs a schema change. For more information about how online schema changes work in CockroachDB, see .
Syntax
Parameters
| Parameter | Description |
|---|---|
ALLALL PRIVILEGES | Revoke all privileges. |
privilege_list | A comma-separated list of to revoke. |
grant_targets | A comma-separated list of database, table, sequence, or function names. The list should be preceded by the object type (e.g., DATABASE mydatabase). If the object type is not specified, all names are interpreted as table or sequence names. |
target_types | A comma-separated list of . |
ALL SEQUENCES IN SCHEMA | Revoke privileges on all sequences in a schema or list of schemas. |
ALL TABLES IN SCHEMA | Revoke privileges on all tables and sequences in a schema or list of schemas. |
ALL FUNCTIONS IN SCHEMA. | Revoke privileges on all in a schema or list of schemas. |
schema_name_list | A comma-separated list of . |
role_spec_list | A comma-separated list of . |
Supported privileges
The following privileges can be revoked:Required privileges
-
To revoke privileges, user revoking privileges must have the
GRANTprivilege on the target , , , or . In addition to theGRANTprivilege, the user revoking privileges must have the privilege being revoked on the target object. For example, a user revoking theSELECTprivilege on a table to another user must have theGRANTandSELECTprivileges on that table. -
To revoke role membership, the user revoking role membership must be a role admin (i.e., members with the
WITH ADMIN OPTION) or a member of theadminrole. To remove membership to theadminrole, the user must haveWITH ADMIN OPTIONon theadminrole.
Considerations
- The
rootuser cannot be revoked from theadminrole.
Limitations
User/role management operations (such as and ) are . As such, they inherit the . For example, schema changes wait for concurrent using the same resources as the schema changes to complete. In the case of being modified inside a transaction, most transactions need access to the set of role memberships. Using the default settings, role modifications require schema leases to expire, which can take up to 5 minutes. This means that elsewhere in the system can cause user/role management operations inside transactions to take several minutes to complete. This can have a cascading effect. When a user/role management operation inside a transaction takes a long time to complete, it can in turn block all user-initiated transactions being run by your application, since the user/role management operation in the transaction has to commit before any other transactions that access role memberships (i.e., most transactions) can make progress. If you want user/role management operations to finish more quickly, and do not care whether concurrent transactions will immediately see the side effects of those operations, set theallow_role_memberships_to_change_during_transaction to true.
When this session variable is enabled, any user/role management operations issued in the current session will only need to wait for the completion of statements in other sessions where allow_role_memberships_to_change_during_transaction is not enabled.
To accelerate user/role management operations across your entire application, you have the following options:
- Set the session variable in all sessions by .
-
Apply the
allow_role_memberships_to_change_during_transactionsetting globally to an entire cluster using the statement:
Examples
Setup
The following examples use MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see . To follow along, run to start a temporary, in-memory cluster with themovr dataset preloaded:
Revoke privileges on databases
Any tables that previously inherited the database-level privileges retain the privileges.
Revoke privileges on specific tables in a database
Revoke privileges on all tables in a database or schema
Revoke system-level privileges on the entire cluster
live above the database level and apply to the entire cluster.root and users have system-level privileges by default, and are capable of revoking it from other users and roles using the REVOKE statement.
For example, the following statement removes the ability to use the statement from the user maxroach by revoking the MODIFYCLUSTERSETTING system privilege:

