database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-08 11:42:09 +03:00
Code Activity

Fire non-deferred AFTER triggers immediately upon query completion,

Browse Source 
rather than when returning to the idle loop.  This makes no particular
difference for interactively-issued queries, but it makes a big difference
for queries issued within functions: trigger execution now occurs before
the calling function is allowed to proceed.  This responds to numerous
complaints about nonintuitive behavior of foreign key checking, such as
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php, and
appears to be required by the SQL99 spec.
Also take the opportunity to simplify the data structures used for the
pending-trigger list, rename them for more clarity, and squeeze out a
bit of space.
This commit is contained in:
Tom Lane
2004-09-10 18:40:09 +00:00
parent 856d1faac1
commit b339d1fff6
17 changed files with 967 additions and 631 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
doc/src/sgml/ref/set_constraints.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.11 2004/09/08 20:47:37 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.12 2004/09/10 18:39:53 tgl Exp $ -->
<refentry id="SQL-SET-CONSTRAINTS">
<refmeta>
<refentrytitle id="SQL-SET-CONSTRAINTS-title">SET CONSTRAINTS</refentrytitle>
@ -34,13 +34,13 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
<para>
Upon creation, a constraint is given one of three
characteristics: <literal>INITIALLY DEFERRED</literal>,
<literal>INITIALLY IMMEDIATE DEFERRABLE</literal>, or
<literal>INITIALLY IMMEDIATE NOT DEFERRABLE</literal>. The third
class 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>.
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>
@ -52,19 +52,22 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
</para>
<para>
When you change the mode of a constraint from <literal>DEFERRED</literal>
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).
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 foreign key constraints are affected by this
setting. Check and unique constraints are always effectively
initially immediate not deferrable.
not deferrable.
</para>
</refsect1>
@ -76,11 +79,7 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
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. If you wish to change the behavior
of a constraint without needing to issue a <command>SET
CONSTRAINTS</command> command in every transaction, specify
<literal>INITIALLY DEFERRED</literal> or <literal>INITIALLY
IMMEDIATE</literal> when you create the constraint.
not appear to have any effect.
</para>
</refsect1>

26
doc/src/sgml/release.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.294 2004/08/30 00:47:31 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.295 2004/09/10 18:39:54 tgl Exp $
-->
<appendix id="release">
@ -336,6 +336,16 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.294 2004/08/30 00:47:31 tgl Exp
whitespace (which has always been ignored).
</para>
</listitem>
<listitem>
<para>
Non-deferred AFTER triggers are now fired immediately after completion
of the triggering query, rather than upon finishing the current
interactive command. This makes a difference when the triggering query
occurred within a function: the trigger is invoked before the function
proceeds to its next operation.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
@ -1424,6 +1434,18 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.294 2004/08/30 00:47:31 tgl Exp
<title>Server-Side Language Changes</title>
<itemizedlist>
<listitem>
<para>
Non-deferred AFTER triggers are now fired immediately after completion
of the triggering query, rather than upon finishing the current
interactive command. This makes a difference when the triggering query
occurred within a function: the trigger is invoked before the function
proceeds to its next operation. For example, if a function inserts
a new row into a table, any non-deferred foreign key checks occur
before proceeding with the function.
</para>
</listitem>
<listitem>
<para>
Allow function parameters to be declared with names (Dennis Bjorklund)
@ -1483,7 +1505,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.294 2004/08/30 00:47:31 tgl Exp
<listitem>
<para>
New plperl server-side language (Command Prompt, Andrew Dunstan)
Major overhaul of plperl server-side language (Command Prompt, Andrew Dunstan)
</para>
</listitem>