From 0510b62d91151b9d8c1fe1aa15c9cf3ffe9bf25b Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Thu, 22 Dec 2011 17:57:17 -0500
Subject: [PATCH] Typo fixes.

All noted by Jaime Casanova.
---
 doc/src/sgml/ref/create_view.sgml | 2 +-
 doc/src/sgml/rules.sgml           | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/ref/create_view.sgml b/doc/src/sgml/ref/create_view.sgml
index 6e86840866..838bf486a3 100644
--- 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>security_barrier</literal>,
+      only supported parameter name is <literal>security_barrier</literal>,
       which should be enabled when a view is intended to provide row-level
       security.  See <xref linkend="rules-privileges"> for full details.
      </para>
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 896cc64ecd..3038fe9adc 100644
--- 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 security, the
     <literal>security_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 (security_barrier) AS
 <para>
     It is important to understand that even a view created with the
     <literal>security_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
-- 
GitLab