A set of one or more existing non-hierarchical category names valid for the constraint_name.
Because all assigned category (non-hierarchical) constraint values assigned to a user are automatically active, SET CONSTRAINT is only useful to specify a subset of the assigned categories for the constraint.
For example, assume that User BOB has 3 country codes, and wants to load a table with data that is to be made available to User CARL who only has rights to see data for his own country. User BOB can use SET SESSION CONSTRAINT to specify only the country code for User CARL when loading the data so Carl can access the data later.
Example: Changing the Row-Level Security Category for a Session
User arn_anderson logs on. The resulting session has a row-level security label consisting of an unclassified level and nato category. As soon as the session is established arn_anderson changes the category to norway.
SET SESSION CONSTRAINT = classification_category (norway) ;
After the SET SESSION CONSTRAINT request executes the session has a label of unclassified and norway.
Assume that later on, the session initiated by arn_anderson wanted to read one of the 3 rows from inventory, so the user submits the following SELECT request.
SELECT * FROM inventory WHERE col_1=12122;
The result of this request would be 0 rows and a value of ‘F’ returned signifying the that the user credentials failed security policy validation, so the constraint predicate added to the query evaluates to FALSE and the row is eliminated from the read.
Teradata Database does not return any rows for this request because the level of unclassified for arn_anderson does not allow him to read secret rows or because his category of norway does not allow him to read rows with a category of nato.