@@ -1876,7 +1876,7 @@ SELECT * FROM phone_number WHERE tricky(person, phone);
18761876 When it is necessary for a view to provide row-level security, the
18771877 <literal>security_barrier</literal> attribute should be applied to
18781878 the view. This prevents maliciously-chosen functions and operators from
1879- being invoked on rows untilafterthe view has done its work. For
1879+ being invoked on rows untilafter the view has done its work. For
18801880 example, if the view shown above had been created like this, it would
18811881 be secure:
18821882<programlisting>
@@ -1893,7 +1893,7 @@ CREATE VIEW phone_number WITH (security_barrier) AS
18931893<para>
18941894 It is important to understand that even a view created with the
18951895 <literal>security_barrier</literal> option is intended to be secure only
1896- in the limited sense that the contents of the invisible tuples will not
1896+ in the limited sense that the contents of the invisible tuples will not be
18971897 passed to possibly-insecure functions. The user may well have other means
18981898 of making inferences about the unseen data; for example, they can see the
18991899 query plan using <command>EXPLAIN</command>, or measure the runtime of