Column-Level Security
Grant or revoke SELECT
privileges to columns in a table. These privileges can be managed separately of table-level privileges, allowing for SELECT
operations on a subset of columns.
Column privileges are only enabled for tables.
Column privileges other than
SELECT
such asUPDATE
,DELETE
are currently unsupported.Column-level security is not supported on queries that use one or more views.
Synopsis
The <entity>
referred to above can either be a role or user.
The above GRANT
and REVOKE
commands can be compounded with other privileges. For example
grants the SELECT
column privilege on the table employees
to test_user
as well as UPDATE
privileges.
When using UPDATE
or DELETE
on a table, any columns used in the WHERE
condition must allow for SELECT
. That is, the entity issuing the command must have sufficient SELECT
privileges to all columns in use. For example, SELECT
privilege on the table being operated on is sufficient.
Currently, when a query utilizes a view, column-level privileges are disabled. In such cases, only table-level privileges are considered. Consequently, queries that might have adequate column-level privileges but also involve a view will result in an insufficient privileges error.
Examples
Grant
SELECT
on a single column.
Revoke
SELECT
on a single column.
The following also revokes column privileges.
Grant
SELECT
on multiple columns.
Revoke
SELECT
on multiple columns.
Granting
SELECT
on any column allows access to metadata.
Allowing
SELECT
privilege on a subset of columns will enable certain queries and disable others.
Any subqueries used within a query will enforce similar column-level security.
Table-level privileges supersede column-level privileges. Revoking column-privilege will not affect table-level privileges.
Last updated