1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.18 2010/01/18 00:32:21 tgl Exp $ -->
<refentry id="SQL-SET-CONSTRAINTS">
<refmeta>
<refentrytitle id="SQL-SET-CONSTRAINTS-title">SET CONSTRAINTS</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>SET CONSTRAINTS</refname>
<refpurpose>set constraint check timing for the current transaction</refpurpose>
</refnamediv>
<indexterm zone="sql-set-constraints">
<primary>SET CONSTRAINTS</primary>
</indexterm>
<refsynopsisdiv>
<synopsis>
SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...] } { DEFERRED | IMMEDIATE }
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>SET CONSTRAINTS</command> sets the behavior of constraint
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.
</para>
<para>
Upon creation, a constraint is given one of three
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>.
</para>
<para>
<command>SET CONSTRAINTS</command> with a list of constraint names changes
the mode of just those constraints (which must all be deferrable). Each
constraint name can be schema-qualified. The
current schema search path is used to find the first matching name if
no schema name is specified. <command>SET CONSTRAINTS ALL</command>
changes the mode of all deferrable constraints.
</para>
<para>
When <command>SET CONSTRAINTS</command> changes the mode of a constraint
from <literal>DEFERRED</literal>
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>
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.
</para>
<para>
Currently, only <literal>UNIQUE</>, <literal>PRIMARY KEY</>,
<literal>REFERENCES</> (foreign key), and <literal>EXCLUDE</>
constraints are affected by this setting.
<literal>NOT NULL</> and <literal>CHECK</> constraints are
always checked immediately when a row is inserted or modified
(<emphasis>not</> at the end of the statement).
Uniqueness and exclusion constraints that have not been declared
<literal>DEFERRABLE</> are also checked immediately.
</para>
<para>
The firing of triggers that are declared as <quote>constraint triggers</>
is also controlled by this setting — they fire at the same time
that the associated constraint should be checked.
</para>
</refsect1>
<refsect1>
<title>Notes</title>
<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>
<para>
This command only alters the behavior of constraints within the
current transaction. Thus, if you execute this command outside of a
transaction block
(<command>BEGIN</command>/<command>COMMIT</command> pair), it will
not appear to have any effect.
</para>
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
This command complies with the behavior defined in the SQL
standard, except for the limitation that, in
<productname>PostgreSQL</productname>, it does not apply to
<literal>NOT NULL</> and <literal>CHECK</> constraints.
Also, <productname>PostgreSQL</productname> checks non-deferrable
uniqueness constraints immediately, not at end of statement as the
standard would suggest.
</para>
</refsect1>
</refentry>
|
