Dean,

* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 8 January 2015 at 18:57, Stephen Frost <sfr...@snowman.net> wrote:
> >> What do you think of the attached rewording?
> >
> > Rewording it this way is a great idea.  Hopefully that will help address
> > the confusion which we've seen.  The only comment I have offhand is:
> > should we should add a sentence to this paragraph about the default-deny
> > policy?
> 
> Yes, good idea, although I think perhaps that sentence should be added
> to the preceding paragraph, after noting that RLS has to be enabled on
> the table for the policies to be applied:

I'm a bit on the fence about these ending up as different paragraphs
then, but ignoring that for the moment, 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.

> Also, perhaps the "ALTER TABLE" in the first paragraph should be
> turned into a link.

Ah, yes, agreed.

        Thanks!

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to