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
SELECTsuch asUPDATE,DELETEare currently unsupported.Column-level security is not supported on queries that use one or more views.
Synopsis
GRANT SELECT (<column1>,<column2>,...<columnN>) ON TABLE <table> TO <entity>;
REVOKE SELECT (<column1>,<column2>,...<columnN>) ON TABLE <table> FROM <entity>;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
CREATE USER test_user (PASSWORD='test');
CREATE TABLE employees (id INT, salary BIGINT);Grant
SELECTon a single column.
Revoke
SELECTon a single column.
The following also revokes column privileges.
Grant
SELECTon multiple columns.
Revoke
SELECTon multiple columns.
Granting
SELECTon any column allows access to metadata.
Allowing
SELECTprivilege 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