From cb052e0bf139c3e51def0966e328f1f5779e442a Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 9 Jul 2001 23:50:32 +0000
Subject: Fix rule rewriter so that new ordering of ON INSERT actions applies
 in cases of qualified rules as well as unqualified ones.  Tweak rules test to
 avoid cluttering output with dummy SELECT results.  Update documentation to
 match code.

---
 doc/src/sgml/ref/create_rule.sgml |  5 +++--
 doc/src/sgml/rules.sgml           | 22 ++++++++++++++++------
 2 files changed, 19 insertions(+), 8 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml
index 430026a7863..a2388b09d11 100644
--- a/doc/src/sgml/ref/create_rule.sgml
+++ b/doc/src/sgml/ref/create_rule.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.23 2001/05/27 09:59:27 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.24 2001/07/09 23:50:31 tgl Exp $
 Postgres documentation
 -->
 
@@ -167,7 +167,8 @@ CREATE
    <replaceable class="parameter">action</replaceable> part of the rule is
    executed.  The <replaceable class="parameter">action</replaceable> is
    done instead of the original query if INSTEAD is specified; otherwise
-   it is done before the original query is performed.
+   it is done after the original query in the case of ON INSERT, or before
+   the original query in the case of ON UPDATE or ON DELETE.
    Within both the <replaceable class="parameter">condition</replaceable>
    and <replaceable class="parameter">action</replaceable>, values from
    fields in the old instance and/or the new instance are substituted for
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 508345a4420..512f5f266bb 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1,3 +1,5 @@
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.14 2001/07/09 23:50:32 tgl Exp $ -->
+
 <Chapter Id="rules">
 <Title>The <ProductName>Postgres</ProductName> Rule System</Title>
 
@@ -1014,6 +1016,16 @@
     for a rule with one action.
 </Para>
 
+<Para>
+    For ON INSERT rules, the original query (if not suppressed by INSTEAD)
+    is done before any actions added by rules.  This allows the actions to
+    see the inserted row(s).  But for ON UPDATE and ON
+    DELETE rules, the original query is done after the actions added by rules.
+    This ensures that the actions can see the to-be-updated or to-be-deleted
+    rows; otherwise, the actions might do nothing because they find no rows
+    matching their qualifications.
+</Para>
+
 <Para>
     The parsetrees generated from rule actions are thrown into the
     rewrite system again and maybe more rules get applied resulting
@@ -1022,8 +1034,8 @@
     or another resultrelation. Otherwise this recursive process will end up in a loop.
     There is a compiled in recursion limit of currently 10 iterations.
     If after 10 iterations there are still update rules to apply the
-    rule system assumes a loop over multiple rule definitions and aborts the
-    transaction.
+    rule system assumes a loop over multiple rule definitions and reports
+    an error.
 </Para>
 
 <Para>
@@ -1262,10 +1274,8 @@
 </Para>
 
 <Para>
-    It is important, that the original parsetree is executed last.
-    The <ProductName>Postgres</ProductName> "traffic cop" does
-    a command counter increment between the execution of the two
-    parsetrees so the second one can see changes made by the first.
+    Here we can see why it is important that the original parsetree is
+    executed last.
     If the UPDATE would have been executed first, all the rows
     are already set to zero, so the logging INSERT
     would not find any row where 0 != shoelace_data.sl_avail.
-- 
cgit v1.2.3