This form of the REVOKE statement revokes privileges on a table or view.
Invocation
This statement can be embedded in an application program or issued through the use of dynamic SQL statements. It is an executable statement that can be dynamically prepared.
Authorization
The privileges held by the authorization ID of the statement must include at least one of the following:
To revoke the CONTROL privilege, either SYSADM or DBADM authority is required.
To revoke the privileges on catalog tables and views, either SYSADM or DBADM authority is required.
Syntax
.-PRIVILEGES--. .-TABLE--.
>>-REVOKE----+-ALL--+-------------+-+--ON----+--------+--------->
| .-,---------------. |
| V | |
'----+-ALTER------+--+-'
+-CONTROL----+
+-DELETE-----+
+-INDEX------+
+-INSERT-----+
+-REFERENCES-+
+-SELECT-----+
'-UPDATE-----'
>-----+-table-name-+-------------------------------------------->
'-view-name--'
.-,------------------------------------.
V |
>----FROM----+-+-------+---authorization-name--+--+------------><
| +-USER--+ |
| '-GROUP-' |
'-PUBLIC--------------------------'
|
Description
If ALL is not used, one or more of the keywords listed below must be used. Each keyword revokes the privilege described, but only as it applies to the tables or views named in the ON clause. The same keyword must not be specified more than once.
Revoking CONTROL privilege from an authorization-name does not revoke other privileges granted to the user on that object.
The ID of the REVOKE statement itself cannot be used. (It is not possible to revoke the privileges from an authorization-name that is the same as the authorization ID of the REVOKE statement.)
Rules
However, if a DBADM or SYSADM explicitly revokes all privileges on the view from the DEFINER, then the record of the DEFINER will not appear in SYSCAT.TABAUTH but nothing will happen to the view - it remains operative.
For example, if a package owned by USER1 contains a SELECT from table T1 and the SELECT privilege for table T1 is revoked from USER1, then the package will be marked invalid. If SELECT authority is re-granted, or if the user holds DBADM authority, the package is successfully rebound when executed.
However, if a DBADM or SYSADM explicitly revokes all privileges on the summary table from the DEFINER, then the record in SYSTABAUTH for the DEFINER will be deleted, but nothing will happen to the summary table - it remains operative.
| Note: | Rules lists the dependencies that objects such as tables and views can have on one another. |
Examples
Example 1: Revoke SELECT privilege on table EMPLOYEE from user ENGLES. There is one row in the SYSCAT.TABAUTH catalog view for this table and grantee and the GRANTEETYPE value is U.
REVOKE SELECT
ON TABLE EMPLOYEE
FROM ENGLES
Example 2: Revoke update privileges on table EMPLOYEE previously granted to all local users. Note that grants to specific users are not affected.
REVOKE UPDATE
ON EMPLOYEE
FROM PUBLIC
Example 3: Revoke all privileges on table EMPLOYEE from users PELLOW and MLI and from group PLANNERS.
REVOKE ALL
ON EMPLOYEE
FROM USER PELLOW, USER MLI, GROUP PLANNERS
Example 4: Revoke SELECT privilege on table CORPDATA.EMPLOYEE from a user named JOHN. There is one row in the SYSCAT.TABAUTH catalog view for this table and grantee and the GRANTEETYPE value is U.
REVOKE SELECT
ON CORPDATA.EMPLOYEE FROM JOHN
or
REVOKE SELECT
ON CORPDATA.EMPLOYEE FROM USER JOHN
Note that an attempt to revoke the privilege from GROUP JOHN would result in an error, since the privilege was not previously granted to GROUP JOHN.
Example 5: Revoke SELECT privilege on table CORPDATA.EMPLOYEE from a group named JOHN. There is one row in the SYSCAT.TABAUTH catalog view for this table and grantee and the GRANTEETYPE value is G.
REVOKE SELECT
ON CORPDATA.EMPLOYEE FROM JOHN
or
REVOKE SELECT
ON CORPDATA.EMPLOYEE FROM GROUP JOHN