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. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers