Re: Add support for restrictive RLS policies

Stephen Frost wrote:

> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > Stephen Frost wrote:

> > > +     <para>
> > > +      If the policy is a "permissive" or "restrictive" policy.  Permissive
> > > +      policies are the default and always add visibillity- they ar "OR"d
> > > +      together to allow the user access to all rows through any of the
> > > +      permissive policies they have access to.  Alternativly, a policy can
> > > +      instead by "restrictive", meaning that the policy will be "AND"d
> > > +      with other restrictive policies and with the result of all of the
> > > +      permissive policies on the table.
> > > +     </para>
> > > +    </listitem>
> > > +   </varlistentry>

Stephen,

> > I dislike the "AND"d and "OR"d spelling of those terms.  Currently they
> > only appear in comments within rowsecurity.c (of your authorship too, I
> > imagine).  I think it'd be better to find actual words for those
> > actions.
> 
> I'm certainly open to suggestions, should you, or anyone else, have
> them.  I'll try and come up with something else, but that really is what
> we're doing- literally using either AND or OR to join the expressions
> together.

I understand, but the words "and" and "or" are not verbs.  I don't know
what are good verbs to use for this but I suppose there must be verbs
related to "conjunction" and "disjunction" ("to conjoin" and "to
disjoin" appear in the Merriam-Webster dictionary but I don't think they
represent the operation very well).  Maybe some native speaker would
have a better suggestion.

> > I don't understand this part.  Didn't you say previously that we already
> > had this capability in 9.5 and you were only exposing it over SQL?  If
> > that is true, how come you need to add a new column to this catalog?
> 
> The capability exists in 9.5 through hooks which are available to
> extensions, see the test_rls_hooks extension.  Those hooks are called
> every time and therefore don't require the information about restrictive
> policies to be tracked in pg_policy, and so they weren't.  Since this is
> adding support for users to define restrictive policies, we need to save
> those policies and therefore we need to distinguish which policies are
> restrictive and which are permissive, hence the need to modify pg_policy
> to track that information.

Ah, okay.  I thought you meant that it was already possible to create a
policy to behave this way, just not using SQL-based DDL.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services