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 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.
Referential integrity is supported only on the Block File System on the primary cluster, not on the Object File System.