On 9 January 2015 at 20:46, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
