On Fri, Dec 2, 2016 at 2:09 AM, Stephen Frost <sfr...@snowman.net> wrote:
> Dean, > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > > On 1 December 2016 at 14:38, Stephen Frost <sfr...@snowman.net> wrote: > > > * Dean Rasheed (dean.a.rash...@gmail.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
