← Back to branch summary

~ubuntu-branches/debian/experimental/postgresql-11/experimental

« back to all changes in this revision

Viewing changes to doc/src/sgml/ref/set_constraints.sgml

  • Committer: Package Import Robot
  • Author(s): Christoph Berg
  • Date: 2018-05-22 14:19:08 UTC
  • Revision ID: package-import@ubuntu.com-20180522141908-0oy9ujs1b5vrda74
Tags: upstream-11~beta1
Import upstream version 11~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/ref/set_constraints.sgml
 
1
<!-- doc/src/sgml/ref/set_constraints.sgml -->
 
2
<refentry id="sql-set-constraints">
 
3
 <indexterm zone="sql-set-constraints">
 
4
  <primary>SET CONSTRAINTS</primary>
 
5
 </indexterm>
 
6
 
 
7
 <refmeta>
 
8
  <refentrytitle>SET CONSTRAINTS</refentrytitle>
 
9
  <manvolnum>7</manvolnum>
 
10
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 
11
 </refmeta>
 
12
 
 
13
 <refnamediv>
 
14
  <refname>SET CONSTRAINTS</refname>
 
15
  <refpurpose>set constraint check timing for the current transaction</refpurpose>
 
16
 </refnamediv>
 
17
 
 
18
 <refsynopsisdiv>
 
19
<synopsis>
 
20
SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...] } { DEFERRED | IMMEDIATE }
 
21
</synopsis>
 
22
 </refsynopsisdiv>
 
23
 
 
24
 <refsect1>
 
25
  <title>Description</title>
 
26
 
 
27
  <para>
 
28
   <command>SET CONSTRAINTS</command> sets the behavior of constraint
 
29
   checking within the current transaction. <literal>IMMEDIATE</literal>
 
30
   constraints are checked at the end of each
 
31
   statement. <literal>DEFERRED</literal> constraints are not checked until
 
32
   transaction commit.  Each constraint has its own
 
33
   <literal>IMMEDIATE</literal> or <literal>DEFERRED</literal> mode.
 
34
  </para>
 
35
 
 
36
  <para>
 
37
   Upon creation, a constraint is given one of three
 
38
   characteristics: <literal>DEFERRABLE INITIALLY DEFERRED</literal>,
 
39
   <literal>DEFERRABLE INITIALLY IMMEDIATE</literal>, or
 
40
   <literal>NOT DEFERRABLE</literal>. The third
 
41
   class is always <literal>IMMEDIATE</literal> and is not affected by the
 
42
   <command>SET CONSTRAINTS</command> command.  The first two classes start
 
43
   every transaction in the indicated mode, but their behavior can be changed
 
44
   within a transaction by <command>SET CONSTRAINTS</command>.
 
45
  </para>
 
46
 
 
47
  <para>
 
48
   <command>SET CONSTRAINTS</command> with a list of constraint names changes
 
49
   the mode of just those constraints (which must all be deferrable).  Each
 
50
   constraint name can be schema-qualified.  The
 
51
   current schema search path is used to find the first matching name if
 
52
   no schema name is specified.  <command>SET CONSTRAINTS ALL</command>
 
53
   changes the mode of all deferrable constraints.
 
54
  </para>
 
55
 
 
56
  <para>
 
57
   When <command>SET CONSTRAINTS</command> changes the mode of a constraint
 
58
   from <literal>DEFERRED</literal>
 
59
   to <literal>IMMEDIATE</literal>, the new mode takes effect
 
60
   retroactively: any outstanding data modifications that would have
 
61
   been checked at the end of the transaction are instead checked during the
 
62
   execution of the <command>SET CONSTRAINTS</command> command.
 
63
   If any such constraint is violated, the <command>SET CONSTRAINTS</command>
 
64
   fails (and does not change the constraint mode).  Thus, <command>SET
 
65
   CONSTRAINTS</command> can be used to force checking of constraints to
 
66
   occur at a specific point in a transaction.
 
67
  </para>
 
68
 
 
69
  <para>
 
70
   Currently, only <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>,
 
71
   <literal>REFERENCES</literal> (foreign key), and <literal>EXCLUDE</literal>
 
72
   constraints are affected by this setting.
 
73
   <literal>NOT NULL</literal> and <literal>CHECK</literal> constraints are
 
74
   always checked immediately when a row is inserted or modified
 
75
   (<emphasis>not</emphasis> at the end of the statement).
 
76
   Uniqueness and exclusion constraints that have not been declared
 
77
   <literal>DEFERRABLE</literal> are also checked immediately.
 
78
  </para>
 
79
 
 
80
  <para>
 
81
   The firing of triggers that are declared as <quote>constraint triggers</quote>
 
82
   is also controlled by this setting &mdash; they fire at the same time
 
83
   that the associated constraint should be checked.
 
84
  </para>
 
85
 </refsect1>
 
86
 
 
87
 <refsect1>
 
88
  <title>Notes</title>
 
89
 
 
90
  <para>
 
91
   Because <productname>PostgreSQL</productname> does not require constraint
 
92
   names to be unique within a schema (but only per-table), it is possible
 
93
   that there is more than one match for a specified constraint name.
 
94
   In this case <command>SET CONSTRAINTS</command> will act on all matches.
 
95
   For a non-schema-qualified name, once a match or matches have been found in
 
96
   some schema in the search path, schemas appearing later in the path are not
 
97
   searched.
 
98
  </para>
 
99
 
 
100
  <para>
 
101
   This command only alters the behavior of constraints within the
 
102
   current transaction.  Issuing this outside of a transaction block
 
103
   emits a warning and otherwise has no effect.
 
104
  </para>
 
105
 </refsect1>
 
106
 
 
107
 <refsect1>
 
108
  <title>Compatibility</title>
 
109
 
 
110
  <para>
 
111
   This command complies with the behavior defined in the SQL
 
112
   standard, except for the limitation that, in
 
113
   <productname>PostgreSQL</productname>, it does not apply to
 
114
   <literal>NOT NULL</literal> and <literal>CHECK</literal> constraints.
 
115
   Also, <productname>PostgreSQL</productname> checks non-deferrable
 
116
   uniqueness constraints immediately, not at end of statement as the
 
117
   standard would suggest.
 
118
  </para>
 
119
 
 
120
 </refsect1>
 
121
</refentry>