Typo fixes.

All noted by Jaime Casanova.
This commit is contained in:
Robert Haas 2011-12-22 17:57:17 -05:00
parent 99b60fc04e
commit 0510b62d91
2 changed files with 3 additions and 3 deletions

View File

@ -104,7 +104,7 @@ CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW <replaceable class="PARAMETER">n
<listitem> <listitem>
<para> <para>
This clause specifies optional parameters for a view; currently, the 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 which should be enabled when a view is intended to provide row-level
security. See <xref linkend="rules-privileges"> for full details. security. See <xref linkend="rules-privileges"> for full details.
</para> </para>

View File

@ -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 When it is necessary for a view to provide row-level security, the
<literal>security_barrier</literal> attribute should be applied to <literal>security_barrier</literal> attribute should be applied to
the view. This prevents maliciously-chosen functions and operators from 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 example, if the view shown above had been created like this, it would
be secure: be secure:
<programlisting> <programlisting>
@ -1893,7 +1893,7 @@ CREATE VIEW phone_number WITH (security_barrier) AS
<para> <para>
It is important to understand that even a view created with the It is important to understand that even a view created with the
<literal>security_barrier</literal> option is intended to be secure only <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 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 of making inferences about the unseen data; for example, they can see the
query plan using <command>EXPLAIN</command>, or measure the runtime of query plan using <command>EXPLAIN</command>, or measure the runtime of