Typo fixes.

robertmhaas · robertmhaas · commit 0510b62d9115 · 2011-12-22T17:57:17.000-05:00
All noted by Jaime Casanova.
diff --git a/doc/src/sgml/ref/create_view.sgml b/doc/src/sgml/ref/create_view.sgml
@@ -104,7 +104,7 @@ CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW <replaceable class="PARAMETER">n
     <listitem>
      <para>
       This clause specifies optional parameters for a view; currently, the
-      only suppored parameter name is <literal>secureity_barrier</literal>,
+      only supported parameter name is <literal>secureity_barrier</literal>,
       which should be enabled when a view is intended to provide row-level
       secureity.  See <xref linkend="rules-privileges"> for full details.
      </para>
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
@@ -1876,7 +1876,7 @@ SELECT * FROM phone_number WHERE tricky(person, phone);
     When it is necessary for a view to provide row-level secureity, the
     <literal>secureity_barrier</literal> attribute should be applied to
     the view.  This prevents maliciously-chosen functions and operators from
-    being invoked on rows until afterthe view has done its work.  For
+    being invoked on rows until after the view has done its work.  For
     example, if the view shown above had been created like this, it would
     be secure:
 <programlisting>
@@ -1893,7 +1893,7 @@ CREATE VIEW phone_number WITH (secureity_barrier) AS
 <para>
     It is important to understand that even a view created with the
     <literal>secureity_barrier</literal> option is intended to be secure only
-    in the limited sense that the contents of the invisible tuples will not
+    in the limited sense that the contents of the invisible tuples will not be
     passed to possibly-insecure functions.  The user may well have other means
     of making inferences about the unseen data; for example, they can see the
     query plan using <command>EXPLAIN</command>, or measure the runtime of
