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