Fixups in content and markup for 7.0 release.

1 files changed, 25 insertions, 8 deletions

diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 2431ffd697..f17cfd77b0 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -854,18 +854,18 @@
 <Para>
     There was a long time where the <ProductName>Postgres</ProductName> 
     rule system was considered broken. The use of rules was not
-    recommended and the only part working where view rules. And also
-    these view rules made problems because the rule system wasn't able
-    to apply them properly on other statements than a SELECT (for
+    recommended and the only part working was view rules. And also
+    these view rules gave problems because the rule system wasn't able
+    to apply them properly on statements other than a SELECT (for
     example an UPDATE
     that used data from a view didn't work).
 </Para>
 
 <Para>
-    During that time, development moved on and many features where
+    During that time, development moved on and many features were
     added to the parser and optimizer. The rule system got more and more
     out of sync with their capabilities and it became harder and harder
-    to start fixing it. Thus, noone did.
+    to start fixing it. Thus, no one did.
 </Para>
 
 <Para>
@@ -2088,7 +2088,7 @@ Merge Join
 </Para>
 
 <Para>
-    Another situation are cases on UPDATE where it depends on the
+    Another situation is cases on UPDATE where it depends on the
     change of an attribute if an action should be performed or
     not. In <ProductName>Postgres</ProductName> version 6.4, the
     attribute specification for rule events is disabled (it will have
@@ -2096,7 +2096,7 @@ Merge Join
     - stay tuned). So for now the only way to
     create a rule as in the shoelace_log example is to do it with
     a rule qualification. That results in an extra query that is
-    performed allways, even if the attribute of interest cannot
+    performed always, even if the attribute of interest cannot
     change at all because it does not appear in the targetlist
     of the initial query. When this is enabled again, it will be
     one more advantage of rules over triggers. Optimization of
@@ -2108,7 +2108,7 @@ Merge Join
     decision. The rule system will know it by looking up the
     targetlist and will suppress the additional query completely
     if the attribute isn't touched. So the rule, qualified or not,
-    will only do it's scan's if there ever could be something to do.
+    will only do its scans if there ever could be something to do.
 </Para>
 
 <Para>
@@ -2121,3 +2121,20 @@ Merge Join
 </Sect1>
 
 </Chapter>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode:sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+sgml-parent-document:nil
+sgml-default-dtd-file:"./reference.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:("/usr/lib/sgml/catalog")
+sgml-local-ecat-files:nil
+End:
+-->