17.20 - Limits on Applying Security Constraints to Tables - Analytics Database - Teradata Vantage

Teradata Vantage™ - Analytics Database Security Administration - 17.20

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-03-07
dita:mapPath
hjo1628096075471.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
zuy1472246340572

A maximum of 5 security constraints can be defined for a table.

A security constraint column cannot be part of a primary index or a partitioning expression, but can participate in a secondary index.

Join indexes and hash indexes must include all constraint columns in the base table.

Limits on CHECK or UNIQUE table constraints:

  • 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 define a CHECK or UNIQUE constraint on a security constraint column.

Do not define row level security on a parent or child referential integrity (RI) table.

If either or both the parent and child RI tables define security constraint columns, the security constraint UDFs are disabled and use of any request that accesses either of the RI tables continues as if the tables had no row level security constraints.