Naming constraints is a good practice to follow because it permits a programmer to debug an embedded SQL or stored procedure application by fetching the name of a violated constraint from the SQLSTATE area. This makes debugging more difficult because it can be very difficult to determine which constraints belong to which system‑defined names.
Row‑level security constraints must be named. CHECK, UNIQUE, FOREIGN KEY, and PRIMARY KEY constraint specifications should be named.
Constraint names must conform to the rules for Teradata Database object names and be unique among all other constraint, primary index, and secondary index names specified on the table.
The characters used to name a constraint can be any of the following:
Teradata Database does not assign system‑generated names to unnamed constraints.