Re: Add support for restrictive RLS policies

On Fri, Dec 2, 2016 at 2:09 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Dean,
>
> * Dean Rasheed (dean(dot)a(dot)rasheed(at)gmail(dot)com) wrote:
> > On 1 December 2016 at 14:38, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > * Dean Rasheed (dean(dot)a(dot)rasheed(at)gmail(dot)com) wrote:
> > >> In get_policies_for_relation() ...
> > >> ... I think it should sort the restrictive policies by name
> > >
> > > Hmmm, is it really the case that the quals will always end up being
> > > evaluated in that order though? Isn't order_qual_clauses() going to
> end
> > > up changing the order based on the relative cost? If the cost is the
> > > same it should maintain the order, but even that could change in the
> > > future based on the comments, no? In short, I'm not entirely sure that
> > > we actually want to be required to always evaluate the quals in order
> of
> > > policy name and we might get complaints if we happen to make that work
> > > today and it ends up being changed later.
> >
> > No, this isn't about the quals that get put into the WHERE clause of
> > the resulting queries. As you say, order_quals_clauses() is going to
> > re-order those anyway. This is about the WithCheckOption's that get
> > generated for UPDATEs and INSERTs, and having those checked in a
> > predictable order. The main advantage to that is to guarantee a
> > predictable error message from self tests that attempt to insert
> > invalid data. This is basically the same as what was done for CHECK
> > constraints in e5f455f59fed0632371cddacddd79895b148dc07.
>
> You know, you said that in your email, and I read it and it made sense
> to me, and then I went off to do something else and came back and
> completely forgot that you were referring to the WITH CHECK case.
>
> You're right, we should order the WithCheckOptions. I'll update the
> patch accordingly.
>

Moved to next CF with "waiting on author" status.

Regards,
Hari Babu
Fujitsu Australia