ADD row_level_security_constraint_name CONSTRAINT - Advanced SQL Engine - Teradata Database

SQL Data Definition Language Syntax and Examples

Product
Advanced SQL Engine
Teradata Database
Release Number
17.00
Published
September 2020
Language
English (United States)
Last Update
2021-01-23
dita:mapPath
wgr1555383704548.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1144
lifecycle
previous
Product Category
Teradata Vantage™

Add a row-level security constraint. The system generates a column with the same name as the security constraint.

The following rules apply when adding a security constraint column:

  • You can ADD up to 5 row-level security constraint columns per ALTER TABLE request.
  • The constraint object must already exist in the database.
  • The specified constraint must not have the same name as another column in the table.
  • You cannot specify any column attributes for the column (for example, name, data type or nullability). The constraint column uses the values specified for the constraint object.
  • A row-level security constraint column cannot be specified as a component of the primary index or partitioning expression for a table.
  • A row-level security constraint can be defined as a component of a secondary index.
  • You cannot add a security constraint to a table with a hash index or a join index.
  • A table can have a maximum of 5 security constraints.
  • For newly added security constraint columns the system uses the session label for the ALTER TABLE request as the column value for each row.
  • You cannot define a CHECK or UNIQUE constraint on a security constraint column.
  • If a table protected by row-level security is defined with a CHECK or UNIQUE constraint, enforcement of the constraint bypasses any security constraints defined for the table.
  • You cannot apply the COMPRESS phrase to a row-level security constraint column.
When using referential integrity (RI) on tables that define security constraint columns, the system does not recognize security constraints when checking referential integrity for either the parent and child RI table. Execution of any request that access such RI tables continues as if the tables had no row-level security constraints.