cannot do is to create a view that directly
    accesses <literal>phone_data</literal>.  (Actually the assistant can, but it will not work since
    every access will be denied during the permission checks.)
    And as soon as the user notices that the assistant opened
    their <literal>phone_number</literal> view, the user can revoke the assistant's access. Immediately, any
    access to the assistant's view would fail.
</para>

<para>
    One might think that this rule-by-rule checking is a security
    hole, but in fact it isn't.   But if it did not work this way, the assistant
    could set up a table with the same columns as <literal>phone_number</literal> and
    copy the data to there once per day. Then it's the assistant's own data and
    the assistant can grant access to everyone they want. A
    <command>GRANT</command> command means, <quote>I trust you</quote>.
    If someone you trust does the thing above, it's time to
    think it over and then use <command>REVOKE</command>.
</para>

<para>
    Note that while views can be used to hide the contents of certain
    columns using the technique shown above, they cannot be used to reliably
    conceal the data in unseen rows unless the
    <literal>security_barrier</literal> flag has been set.  For example,
    the following view is insecure:
<programlisting>
CREATE VIEW phone_number AS
    SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
</programlisting>
    This view might seem secure, since the rule system will rewrite any
    <command>SELECT</command> from <literal>phone_number</literal> into a
    <command>SELECT</command> from <literal>phone_data</literal> and add the
    qualification that only entries where <literal>phone</literal> does not begin
    with 412 are wanted.  But if the user can create their own functions,
    it is not difficult to convince the planner to execute the user-defined
    function prior to the <function>NOT LIKE</function> expression.
    For example:
<programlisting>
CREATE FUNCTION tricky(text, text) RETURNS bool AS $$
BEGIN
    RAISE NOTICE '% =&gt; %', $1, $2;
    RETURN true;
END;
$$ LANGUAGE plpgsql COST 0.0000000000000000000001;

SELECT * FROM phone_number WHERE tricky(person, phone);
</programlisting>
    Every person and phone number in the <literal>phone_data</literal> table will be
    printed as a <literal>NOTICE</literal>, because the planner will choose to
    execute the inexpensive <function>tricky</function> function before the
    more expensive <function>NOT LIKE</function>.  Even if the user is
    prevented from defining new functions, built-in functions can be used in
    similar attacks.  (For example, most casting functions include their
    input values in the error messages they produce.)
</para>

<para>
    Similar considerations apply to update rules. In the examples of
    the previous section, the owner of the tables in the example
    database could grant the privileges <literal>SELECT</literal>,
    <literal>INSERT</literal>, <literal>UPDATE</literal>, and <literal>DELETE</literal> on
    the <literal>shoelace</literal> view to someone else, but only
    <literal>SELECT</literal> on <literal>shoelace_log</literal>. The rule action to
    write log entries will still be executed successfully, and that
    other user could see the log entries.  But they could not create fake
    entries, nor could they manipulate or remove existing ones.  In this
    case, there is no possibility of subverting the rules by convincing
    the planner to alter the order of operations, because the only rule
    which references <literal>shoelace_log</literal> is an unqualified
    <literal>INSERT</literal>.  This might not be true in more complex scenarios.
</para>

<para>
    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 passed values