Typically, the object name is an identifier. For URIs, it is a string literal.

Required privileges:

Only administrative users (initially, a predefined set of users specified in the Sentry service configuration
file) can use this statement.

The WITH GRANT OPTION clause allows members of the specified role to issue
GRANT and REVOKE statements for those same privileges
Hence, if a role has the ALL privilege on a database and the WITH GRANT
OPTION set, users granted that role can execute GRANT/REVOKE
statements only for that database or child tables of the database. This means a user could revoke the
privileges of the user that provided them the GRANT OPTION.

Impala does not currently support revoking only the WITH GRANT OPTION from a privilege
previously granted to a role. To remove the WITH GRANT OPTION, revoke the privilege and
grant it again without the WITH GRANT OPTION flag.

The ability to grant or revoke SELECT privilege on specific columns is available
in Impala 2.3 and higher. See the documentation for Apache Sentry for details.

Compatibility:

The Impala GRANT and REVOKE statements are available in
Impala 2.0 and later.

In Impala 1.4 and later, Impala can make use of any roles and privileges specified by the
GRANT and REVOKE statements in Hive, when your system is configured to
use the Sentry service instead of the file-based policy mechanism.

The Impala GRANT and REVOKE statements for privileges do not require
the ROLE keyword to be repeated before each role name, unlike the equivalent Hive
statements.

Currently, each Impala GRANT or REVOKE statement can only grant or
revoke a single privilege to or from a single role.

Cancellation: Cannot be cancelled.

HDFS permissions: This statement does not touch any HDFS files or directories,
therefore no HDFS permissions are required.

Kudu considerations:

Access to Kudu tables must be granted to and revoked from roles as usual.
Only users with ALL privileges on SERVER can create external Kudu tables.
Currently, access to a Kudu table is "all or nothing":
enforced at the table level rather than the column level, and applying to all
SQL operations rather than individual statements such as INSERT.
Because non-SQL APIs can access Kudu data without going through Sentry
authorization, currently the Sentry support is considered preliminary
and subject to change.