2020-05-15 14:52:24 +02:00
|
|
|
<!--
|
|
|
|
doc/src/sgml/ref/set_constraints.sgml
|
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-set-constraints">
|
2014-02-24 03:25:35 +01:00
|
|
|
<indexterm zone="sql-set-constraints">
|
|
|
|
<primary>SET CONSTRAINTS</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<refmeta>
|
2010-04-03 09:23:02 +02:00
|
|
|
<refentrytitle>SET CONSTRAINTS</refentrytitle>
|
2008-11-14 11:22:48 +01:00
|
|
|
<manvolnum>7</manvolnum>
|
2000-06-18 23:24:54 +02:00
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
</refmeta>
|
2003-05-04 04:23:16 +02:00
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<refnamediv>
|
|
|
|
<refname>SET CONSTRAINTS</refname>
|
2010-01-18 01:32:21 +01:00
|
|
|
<refpurpose>set constraint check timing for the current transaction</refpurpose>
|
2000-06-18 23:24:54 +02:00
|
|
|
</refnamediv>
|
2003-05-04 04:23:16 +02:00
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
<refsynopsisdiv>
|
2003-05-04 04:23:16 +02:00
|
|
|
<synopsis>
|
2003-09-22 02:16:58 +02:00
|
|
|
SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...] } { DEFERRED | IMMEDIATE }
|
2003-05-04 04:23:16 +02:00
|
|
|
</synopsis>
|
2000-06-18 23:24:54 +02:00
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>SET CONSTRAINTS</command> sets the behavior of constraint
|
2004-09-08 22:47:37 +02:00
|
|
|
checking within the current transaction. <literal>IMMEDIATE</literal>
|
|
|
|
constraints are checked at the end of each
|
|
|
|
statement. <literal>DEFERRED</literal> constraints are not checked until
|
|
|
|
transaction commit. Each constraint has its own
|
|
|
|
<literal>IMMEDIATE</literal> or <literal>DEFERRED</literal> mode.
|
2002-08-17 14:15:49 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-09-08 22:47:37 +02:00
|
|
|
Upon creation, a constraint is given one of three
|
2004-09-10 20:40:09 +02:00
|
|
|
characteristics: <literal>DEFERRABLE INITIALLY DEFERRED</literal>,
|
|
|
|
<literal>DEFERRABLE INITIALLY IMMEDIATE</literal>, or
|
|
|
|
<literal>NOT DEFERRABLE</literal>. The third
|
|
|
|
class is always <literal>IMMEDIATE</literal> and is not affected by the
|
|
|
|
<command>SET CONSTRAINTS</command> command. The first two classes start
|
|
|
|
every transaction in the indicated mode, but their behavior can be changed
|
|
|
|
within a transaction by <command>SET CONSTRAINTS</command>.
|
2004-09-08 22:47:37 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>SET CONSTRAINTS</command> with a list of constraint names changes
|
2010-01-18 01:32:21 +01:00
|
|
|
the mode of just those constraints (which must all be deferrable). Each
|
|
|
|
constraint name can be schema-qualified. The
|
2006-04-27 02:33:46 +02:00
|
|
|
current schema search path is used to find the first matching name if
|
2009-07-29 22:56:21 +02:00
|
|
|
no schema name is specified. <command>SET CONSTRAINTS ALL</command>
|
2006-04-27 02:33:46 +02:00
|
|
|
changes the mode of all deferrable constraints.
|
2004-09-08 22:47:37 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2004-09-10 20:40:09 +02:00
|
|
|
When <command>SET CONSTRAINTS</command> changes the mode of a constraint
|
|
|
|
from <literal>DEFERRED</literal>
|
2004-09-08 22:47:37 +02:00
|
|
|
to <literal>IMMEDIATE</literal>, the new mode takes effect
|
|
|
|
retroactively: any outstanding data modifications that would have
|
|
|
|
been checked at the end of the transaction are instead checked during the
|
|
|
|
execution of the <command>SET CONSTRAINTS</command> command.
|
|
|
|
If any such constraint is violated, the <command>SET CONSTRAINTS</command>
|
2004-09-10 20:40:09 +02:00
|
|
|
fails (and does not change the constraint mode). Thus, <command>SET
|
|
|
|
CONSTRAINTS</command> can be used to force checking of constraints to
|
|
|
|
occur at a specific point in a transaction.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Currently, only <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>,
|
|
|
|
<literal>REFERENCES</literal> (foreign key), and <literal>EXCLUDE</literal>
|
2010-01-18 01:32:21 +01:00
|
|
|
constraints are affected by this setting.
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>NOT NULL</literal> and <literal>CHECK</literal> constraints are
|
2009-07-29 22:56:21 +02:00
|
|
|
always checked immediately when a row is inserted or modified
|
2017-10-09 03:44:17 +02:00
|
|
|
(<emphasis>not</emphasis> at the end of the statement).
|
2010-01-18 01:32:21 +01:00
|
|
|
Uniqueness and exclusion constraints that have not been declared
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>DEFERRABLE</literal> are also checked immediately.
|
2009-07-29 22:56:21 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The firing of triggers that are declared as <quote>constraint triggers</quote>
|
2009-07-29 22:56:21 +02:00
|
|
|
is also controlled by this setting — they fire at the same time
|
|
|
|
that the associated constraint should be checked.
|
2000-06-18 23:24:54 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
2003-05-04 04:23:16 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
2000-07-14 17:27:14 +02:00
|
|
|
|
2010-01-18 01:32:21 +01:00
|
|
|
<para>
|
|
|
|
Because <productname>PostgreSQL</productname> does not require constraint
|
|
|
|
names to be unique within a schema (but only per-table), it is possible
|
|
|
|
that there is more than one match for a specified constraint name.
|
|
|
|
In this case <command>SET CONSTRAINTS</command> will act on all matches.
|
|
|
|
For a non-schema-qualified name, once a match or matches have been found in
|
|
|
|
some schema in the search path, schemas appearing later in the path are not
|
|
|
|
searched.
|
|
|
|
</para>
|
|
|
|
|
2003-05-04 04:23:16 +02:00
|
|
|
<para>
|
|
|
|
This command only alters the behavior of constraints within the
|
2013-12-02 18:51:28 +01:00
|
|
|
current transaction. Issuing this outside of a transaction block
|
|
|
|
emits a warning and otherwise has no effect.
|
2003-05-04 04:23:16 +02:00
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
2000-07-14 17:27:14 +02:00
|
|
|
|
2003-05-04 04:23:16 +02:00
|
|
|
<para>
|
|
|
|
This command complies with the behavior defined in the SQL
|
2003-09-11 23:42:20 +02:00
|
|
|
standard, except for the limitation that, in
|
2010-01-18 01:32:21 +01:00
|
|
|
<productname>PostgreSQL</productname>, it does not apply to
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>NOT NULL</literal> and <literal>CHECK</literal> constraints.
|
2010-01-18 01:32:21 +01:00
|
|
|
Also, <productname>PostgreSQL</productname> checks non-deferrable
|
|
|
|
uniqueness constraints immediately, not at end of statement as the
|
|
|
|
standard would suggest.
|
2003-05-04 04:23:16 +02:00
|
|
|
</para>
|
2004-09-08 22:47:37 +02:00
|
|
|
|
2000-06-18 23:24:54 +02:00
|
|
|
</refsect1>
|
|
|
|
</refentry>
|