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 6e868408662..838bf486a3d 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 896cc64ecd2..3038fe9adc0 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