On 9 January 2015 at 20:46, Stephen Frost <sfrost@snowman.net> wrote:
> I'd suggest we further clarify
> with:
>
> The <command>CREATE POLICY</command> command defines a new policy for a
> table. Note that row level security must also be enabled on the table using
> <command>ALTER TABLE</command> in order for created policies to be applied.
> Once row level security has been enabled, a default-deny policy is used and
> no rows in the table are visible, except to the table owner or
> superuser, unless permitted by a specific policy.
>
> A policy permits SELECT, INSERT, UPDATE or DELETE commands to access rows
> in a table that has row level security enabled. Access to existing table
> rows is granted if they match a policy expression specified via USING,
> while new rows that would be created via INSERT or UPDATE are checked
> against policy expressions specified via WITH CHECK. For policy
> expressions specified via USING which grant access to existing rows, the
> system will generally test the policy expressions prior to any
> qualifications that appear in the query itself, in order to the prevent the
> inadvertent exposure of the protected data to user-defined functions which
> might not be trustworthy. However, functions and operators marked by the
> system (or the system administrator) as LEAKPROOF may be evaluated before
> policy expressions, as they are assumed to be trustworthy.
>
Looks good to me.
Regards,
Dean