|
|
|
@ -403,6 +403,33 @@ CREATE TABLE products ( |
|
|
|
|
ensure that a column does not contain null values, the not-null |
|
|
|
|
constraint described in the next section can be used. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
|
<para> |
|
|
|
|
<productname>PostgreSQL</productname> does not support |
|
|
|
|
<literal>CHECK</literal> constraints that reference table data other than |
|
|
|
|
the new or updated row being checked. While a <literal>CHECK</literal> |
|
|
|
|
constraint that violates this rule may appear to work in simple |
|
|
|
|
tests, it cannot guarantee that the database will not reach a state |
|
|
|
|
in which the constraint condition is false (due to subsequent changes |
|
|
|
|
of the other row(s) involved). This would cause a database dump and |
|
|
|
|
reload to fail. The reload could fail even when the complete |
|
|
|
|
database state is consistent with the constraint, due to rows not |
|
|
|
|
being loaded in an order that will satisfy the constraint. If |
|
|
|
|
possible, use <literal>UNIQUE</literal>, <literal>EXCLUDE</literal>, |
|
|
|
|
or <literal>FOREIGN KEY</literal> constraints to express |
|
|
|
|
cross-row and cross-table restrictions. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
If what you desire is a one-time check against other rows at row |
|
|
|
|
insertion, rather than a continuously-maintained consistency |
|
|
|
|
guarantee, a custom <link linkend="triggers">trigger</link> can be used |
|
|
|
|
to implement that. (This approach avoids the dump/reload problem because |
|
|
|
|
<application>pg_dump</application> does not reinstall triggers until after |
|
|
|
|
reloading data, so that the check will not be enforced during a dump/reload.) |
|
|
|
|
</para> |
|
|
|
|
</note> |
|
|
|
|
</sect2> |
|
|
|
|
|
|
|
|
|
<sect2> |
|
|
|
|