Check constraint

<h2 id="definition">Definition</h2>
Each check constraint has to be defined in the CREATE TABLE or ALTER TABLE statement using the syntax:

CREATE TABLE table_name (
 ...,
 CONSTRAINT constraint_name CHECK ( predicate ),
 ...
)

ALTER TABLE table_name
 ADD CONSTRAINT constraint_name CHECK ( predicate )

If the check constraint refers to a single column only, it is possible to specify the constraint as part of the column definition.

CREATE TABLE table_name (
 ...
 column_name type CHECK ( predicate ),
 ...
)

<h2 id="not-null-constraint">NOT NULL constraint</h2>
A NOT <a href="/facts/Null_(SQL)/RBnXTe7k">NULL</a> constraint is functionally equivalent to the following check constraint with an IS NOT NULL predicate:

CHECK (column IS NOT NULL)

Some <a href="/facts/Relational_database_management_system/pEKGmJLy">relational database management systems</a> are able to optimize performance when the NOT NULL constraint syntax is used as opposed to the CHECK constraint syntax given above.<a class="footnote-ref" id="fnref:1" href="#fn:1">1</a>

<h2 id="common-restrictions">Common restrictions</h2>
Most database management systems restrict check constraints to a single row, with access to constants and deterministic functions, but not to data in other tables, or to data invisible to the current transaction because of <a href="/facts/Transaction_isolation/DnrN4uew">transaction isolation</a>.
Such constraints are not truly table check constraints but rather row check constraints. Because these constraints are generally only verified when a row is directly updated (for performance reasons,) and often implemented as implied INSERT or UPDATE triggers, <a href="/facts/Integrity_constraints/g3XGbKIH">integrity constraints</a> could be violated by indirect action were it not for these limitations. Furthermore, otherwise-valid modifications to these records would then be prevented by the CHECK constraint. Some examples of dangerous constraints include:

<ul><li>CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)</li>
<li>CHECK (dateInserted = CURRENT_DATE)</li>
<li>CHECK (countItems = RAND())</li></ul>
User-defined <a href="/facts/Database_trigger/yhI7KW6H">triggers</a> can be used to work around these restrictions. Although similar in implementation, it is semantically clear that triggers will only be fired when the table is directly modified, and that it is the designer's responsibility to handle indirect, important changes in other tables; constraints on the other hand are intended to be "true at all times" regardless of the user's actions or the designer's lack of foresight.

<h2 id="references">References</h2>

<ol>
<li id="fn:1">PostgreSQL 13 Documentation, Chapter 5. Data Definition, Section 5.4.2. Not-Null Constraints, Website: https://www.postgresql.org/docs/13/ddl-constraints.html, Accessed on Jan 9, 2021 <a href="https://www.postgresql.org/docs/13/ddl-constraints.html" target="_blank">https://www.postgresql.org/docs/13/ddl-constraints.html</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
</ol>

Check constraint open-in-new

Check constraint