Use FROM clause in example UPDATE commands where appropriate. Also

remove long-obsolete statement that there isn't a check for infinite
recursion in view rules.

diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 79bb1629a8799c86a4907fad0782ec2d43932698..8ee30a63b4ac85c08ab99d687d50ef27cea2e985 100644 (file)
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1,4 +1,4 @@
-
+
 
 
 The Rule System
@@ -649,21 +649,6 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
     collapsing the query tree is an optimization that the rewrite
     system doesn't have to concern itself with.
    
-
-   
-    
-    There is currently no recursion stopping mechanism for view rules
-    in the rule system (only for the other kinds of rules).  This
-    doesn't hurt much, because the only way to push this into an
-    endless loop (bloating up the server process until it reaches the memory
-    limit) is to create tables and then setup the view rules by hand
-    with CREATE RULE in such a way, that one
-    selects from the other that selects from the one.  This could
-    never happen if CREATE VIEW is used because for
-    the first CREATE VIEW, the second relation does
-    not exist and thus the first view cannot select from the second.
-    
-   
 
 
 
@@ -688,7 +673,7 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
 
 SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
 
-UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;
+UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;
 
 
     are nearly identical.  In particular:
@@ -730,7 +715,7 @@ UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;
     as
 
 
-UPDATE t1 SET a = t1.a, b = t2.b WHERE t1.a = t2.a;
+UPDATE t1 SET a = t1.a, b = t2.b FROM t2 WHERE t1.a = t2.a;
 
 
     and thus the executor run over the join will produce exactly the
@@ -756,11 +741,12 @@ SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
     To resolve this problem, another entry is added to the target list
     in UPDATE (and also in
     DELETE) statements: the current tuple ID
-    (CTID).CTID  This is a system column containing the
+    (CTID).CTID
+    This is a system column containing the
     file block number and position in the block for the row. Knowing
     the table, the CTID can be used to retrieve the
-    original row of t1 to be updated.  After adding the CTID
-    to the target list, the query actually looks like
+    original row of t1 to be updated.  After adding the
+    CTID to the target list, the query actually looks like
 
 
 SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
@@ -774,8 +760,7 @@ SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
     CTID pointed to, the cmax and
     xmax entries are set to the current command counter
     and current transaction ID. Thus the old row is hidden, and after
-    the transaction committed the vacuum cleaner can really move it
-    out.
+    the transaction commits the vacuum cleaner can really remove it.