The following types of permissions can be revoked:
- Delete data from a specific table.
- Insert data into a specific table.
- Create a foreign key reference to the named table or to a subset of columns
from a table.
- Select data from a table, view, or a subset of columns in a table.
- Create a trigger on a table.
- Update data in a table or in a subset of columns in a table.
- Run a specified routine (function or procedure).
Before you issue a REVOKE statement, check that the derby.database.sqlAuthorization property
is set to true. The derby.database.sqlAuthorization property
enables the SQL Authorization mode.
You can revoke privileges from an
object if you are the owner of the object or the
database owner.
The
syntax that you use for the REVOKE statement depends on whether you are revoking
privileges to a table or to a routine.
Syntax for tablesREVOKE privilege-type ON [ TABLE ] { | } FROM granteesRevoking a privilege without specifying a column list revokes
the privilege for all of the columns in the table.
Syntax for routinesREVOKE EXECUTE ON { FUNCTION | PROCEDURE } routine-designator FROM grantees RESTRICTYou
must use the RESTRICT clause on REVOKE statements for routines. The RESTRICT
clause specifies that the EXECUTE privilege cannot be revoked if the specified
routine is used in a view, trigger, or constraint, and the privilege is being
revoked from the owner of the view, trigger, or constraint.
privilege-type
{
ALL PRIVILEGES |
DELETE |
INSERT |
REFERENCES [column list] |
SELECT [column list] |
TRIGGER |
UPDATE [column list}
}Use the ALL PRIVILEGES privilege type to revoke all of
the permissions from the user for the specified table.
Use the DELETE
privilege type to revoke permission to delete rows from the specified table.
Use
the INSERT privilege type to revoke permission to insert rows into the specified
table.
Use the REFERENCES privilege type to revoke permission to create
a foreign key reference to the specified table. If a column list is specified
with the REFERENCES privilege, the permission is revoked on only the foreign
key reference to the specified columns.
Use the SELECT privilege type
to revoke permission to perform SELECT statements on a table or view. If a
column list is specified with the SELECT privilege, the permission is revoked
on only those columns. If no column list is specified, then the privilege
is valid on all of the columns in the table.
Use the TRIGGER privilege
type to revoke permission to create a trigger on the specified table.
Use
the UPDATE privilege type to revoke permission to use the UPDATE statement
on the specified table. If a column list is specified, the permission is revoked
only on the specified columns.
grantees{ authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *You can revoke the privileges from specific users or from
all users. Use the keyword PUBLIC to specify all users. The privileges revoked
from PUBLIC and from individual users are independent privileges. For example,
a SELECT privilege on table t is granted to both PUBLIC and
to the authorization ID harry. The SELECT privilege is later
revoked from the authorization ID harry, but the authorization
ID harry can access the table t through
the PUBLIC privilege.
You cannot revoke the privileges
of the owner of an object.
routine-designator
{
qualified-name [ signature ]
}
Cascading object dependenciesFor views, triggers,
and constraints, if the privilege on which the object depends on is revoked,
the object is automatically dropped. does
not try to determine if you have other privileges that can replace the privileges
that are being revoked. For more information, see "SQL standard authorization"
in the Derby Developer's Guide.
LimitationsThe following limitations apply to the
REVOKE statement:
- Table-level privileges
- All of the table-level privilege types for a specified grantee and table
ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is
granted the SELECT and DELETE privileges on table user1.t1,
a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and
the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV
fields are set to Y. The remaining privilege type fields are set to N.
When
a grantee creates an object that relies on one of the privilege types, the engine tracks the dependency
of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates
the view v1 by using the statement SELECT * FROM
user1.t1, the dependency manager tracks the dependency of view v1 on
the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1).
The dependency manager knows only that the view is dependent on a privilege
type in that specific row, but does not track exactly which privilege type
the view is dependent on.
When a REVOKE statement for a table-level
privilege is issued for a grantee and table ID, all of the objects that are
dependent on the grantee and table ID are dropped. For example, if user1 revokes
the DELETE privilege on table t1 from user2,
the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1)
is modified by the REVOKE statement. The dependency manager sends a revoke
invalidation message to the view user2.v1 and the view is
dropped even though the view is not dependent on the DELETE privilege for
GRANTEE(user2), TABLEID(user1.t1).
- Column-level privileges
- Only one type of privilege for a specified grantee and table ID are stored
in one row in the SYSCOLPERMS system table. For example, when user2 is
granted the SELECT privilege on table user1.t1 for columns
c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2,
the TABLEID contains user1.t1, the TYPE field contains S,
and the COLUMNS field contains c12, c13.
When a grantee
creates an object that relies on the privilege type and the subset of columns
in a table ID, the engine
tracks the dependency of the object on the specific row in the SYSCOLPERMS
table. For example, user2 creates the view v1 by
using the statement SELECT c11 FROM user1.t1, the dependency
manager tracks the dependency of view v1 on the row in SYSCOLPERMS
for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).
The dependency manager knows that the view is dependent on the SELECT privilege
type, but does not track exactly which columns the view is dependent on.
When
a REVOKE statement for a column-level privilege is issued for a grantee, table
ID, and type, all of the objects that are dependent on the grantee, table
ID, and type are dropped. For example, if user1 revokes the
SELECT privilege on column c12 on table user1.t1 from user2,
the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1),
TYPE(S) is modified by the REVOKE statement. The dependency manager sends
a revoke invalidation message to the view user2.v1 and the
view is dropped even though the view is not dependent on the column c12 for
GRANTEE(user2), TABLEID(user1.t1), TYPE(S).
Revoke examplesTo revoke the SELECT privilege
on table t from the authorization IDs maria and harry,
use the following syntax:REVOKE SELECT ON TABLE t FROM maria,harry
To
revoke the UPDATE and TRIGGER privileges on table t from
the authorization IDs anita and zhi, use
the following syntax:REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi
To
revoke the SELECT privilege on table s.v from all users,
use the following syntax:REVOKE SELECT ON TABLE s.v FROM PUBLIC
To
revoke the UPDATE privilege on columns c1 and c2 of
table s.v from all users, use the following syntax:REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC
To revoke the EXECUTE privilege on procedure p from the
authorization ID george, use the following syntax:
REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT