Re: Add support for restrictive RLS policies
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thom Brown <thom@linux.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-12-01T15:03:38Z
Lists: pgsql-hackers
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. Regards, Dean
Commits
-
Add support for restrictive RLS policies
- 093129c9d9fc 10.0 landed
-
Include <sys/select.h> where needed
- 51c3e9fade76 10.0 cited
-
Apply table and domain CHECK constraints in name order.
- e5f455f59fed 9.5.0 cited