Delete access permissions.
REVOKE [GRANT OPTION FOR] { {SELECT | INSERT | UPDATE | DELETE
| REFERENCES | TRIGGER | TRUNCATE } [, ...] | ALL [PRIVILEGES] }
ON { [TABLE] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
FROM { [ GROUP ] role_name | PUBLIC} [, ...]
[CASCADE | RESTRICT]
REVOKE [ GRANT OPTION FOR ] { { SELECT | INSERT | UPDATE
| REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
REVOKE [GRANT OPTION FOR] { {USAGE | SELECT | UPDATE} [,...]
| ALL [PRIVILEGES] }
ON { SEQUENCE sequence_name [, ...]
| ALL SEQUENCES IN SCHEMA schema_name [, ...] }
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[CASCADE | RESTRICT]
REVOKE [GRANT OPTION FOR] { {CREATE | CONNECT
| TEMPORARY | TEMP} [, ...] | ALL [PRIVILEGES] }
ON DATABASE database_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC} [, ...]
[CASCADE | RESTRICT]
REVOKE [ GRANT OPTION FOR ]
{ USAGE | ALL [ PRIVILEGES ] }
ON DOMAIN domain_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
REVOKE [ GRANT OPTION FOR ]
{ USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN DATA WRAPPER fdw_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
REVOKE [ GRANT OPTION FOR ]
{ USAGE | ALL [ PRIVILEGES ] }
ON FOREIGN SERVER server_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
REVOKE [GRANT OPTION FOR] {EXECUTE | ALL [PRIVILEGES]}
ON { FUNCTION funcname ( [[argmode] [argname] argtype
[, ...]] ) [, ...]
| ALL FUNCTIONS IN SCHEMA schema_name [, ...] }
FROM { [ GROUP ] role_name | PUBLIC} [, ...]
[CASCADE | RESTRICT]
REVOKE [GRANT OPTION FOR] {USAGE | ALL [PRIVILEGES]}
ON LANGUAGE langname [, ...]
FROM { [ GROUP ] role_name | PUBLIC} [, ...]
[ CASCADE | RESTRICT ]
REVOKE [GRANT OPTION FOR] { {CREATE | USAGE} [, ...]
| ALL [PRIVILEGES] }
ON SCHEMA schema_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC} [, ...]
[CASCADE | RESTRICT]
REVOKE [GRANT OPTION FOR] { CREATE | ALL [PRIVILEGES] }
ON TABLESPACE tablespacename [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[CASCADE | RESTRICT]
REVOKE [ GRANT OPTION FOR ]
{ USAGE | ALL [ PRIVILEGES ] }
ON TYPE type_name [, ...]
FROM { [ GROUP ] role_name | PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
REVOKE [ADMIN OPTION FOR] parent_role [, ...]
FROM [ GROUP ] member_role [, ...]
[CASCADE | RESTRICT]The REVOKE command revokes previously granted privileges from one or more roles. The keyword PUBLIC refers to an implicitly defined group of all roles.
See the description of the GRANT command for the meaning of the privilege type.
Note that any particular role will have the sum of the privileges granted to it directly, the privileges granted to any roles of the current member of that role, and the privileges granted to PUBLIC. Therefore, for example, revoking SELECT privileges from PUBLIC does not necessarily mean that all roles lose SELECT privileges to that object: those who grant it directly or through other roles still have that privilege. Similarly, revoking SELECT from the user may not prevent that user from using SELECT if PUBLIC or other membership roles still have SELECT permissions.
If GRANT OPTION FOR is specified, only the grant option for the privilege is revoked, not the privilege itself. Otherwise, both privileges and grant options will be revoked.
If a role has privileges with the "Grant" option and grants it to other roles, the privileges owned by those other roles are called "Subordinate Privileges". If the privileges or grant options held by the first role are revoked and there are subordinate privileges, those subordinate privileges will also be revoked if CASCADE is specified, otherwise the revocation operation will fail. This recursive revocation only affects the privileges granted by the role chain traceable to the roles that can be traced to this REVOKE command object. Therefore, if privileges are also granted through other roles, the affected role can effectively retain privileges.
When you revoke privileges to a table, the YMatrix database also revokes the corresponding column privileges for each column of the table (if any). On the other hand, if the role has been granted privileges for a table, revoking the same privilege from a separate column will be invalid.
When revoking role membership, GRANT OPTION is changed to ADMIN OPTION, but the behavior is similar.
See GRANT
The user can only revoke those privileges directly granted by the user. For example, if User A grants user B a privilege with a grant option, and User B in turn grants it to User C, User A cannot revoke the privilege directly from C. Instead, user A can revoke the grant option of user B and use the CASCADE option to revoke the privileges from user C in turn. For example, if both A and B grant the same privileges to C, A can revoke his own grant, but cannot revoke B's grant, so C actually still has privileges.
When the non-owner of the object tries to REVOKE privileges to the object, the command will fail completely if the user does not have any privileges to the object. The command continues to execute as long as there are certain privileges, but it will revoke only those privileges that the user has granted options. If no grant option is retained, the REVOKE ALL PRIVILEGES form will issue a warning message, and if no grant option for any privileges explicitly specified in the command is retained, the other form will issue a warning. (In principle, these declarations also apply to object owners, but this will never happen because the YMatrix database always treats the owner as an object with all grant options.)
If the superuser chooses to issue the GRANT or REVOKE command, the YMatrix database executes the command as if it was issued by the owner of the affected object. Since all privileges end up coming from the object owner (probably indirectly through granting the option chain), the superuser can revoke all privileges, but as mentioned above, this may require the use of CASCADE.
REVOKE can also be called by a member who is not the owner of the affected object but owns the role of the object, or a member who holds a role with WITH GRANT OPTION privileges to the object. In this case, the YMatrix database will execute the command as if it was issued by a role included by a user who actually owns the object or has WITH GRANT OPTION privileges. For example, if table t1 is owned by role g1 and role u1 is its member, then u1 can revoke the privileges recorded on t1 as granted by g1. This includes authorizations made by u1 and other members of role g1.
If a role executing REVOKE holds privileges indirectly through multiple role member paths, no specified which contains role will be used to execute the command. In this case, the best practice is to use SET ROLE to become a specific role to be REVOKE. Otherwise, it may result in revoking privileges other than the privilege you want, or no privileges at all.
Use the \dp meta command of psql to get information about existing privileges for tables and columns. You can also use other \d meta commands to display privileges for non-table objects.
Revoke public's insertion privilege on table films:
REVOKE INSERT ON films FROM PUBLIC;Sally revoke all privileges from the role in the topten view. Note that this actually means revoking all privileges granted by the current role (if not the superuser).
REVOKE ALL PRIVILEGES ON topten FROM sally;Revoke membership of role admins from user joe:
REVOKE admins FROM joe;The compatibility description for the GRANT command also applies to REVOKE.
According to the standard, RESTRICT or CASCADE is required, but by default the YMatrix database assumes RESTRICT.