On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost <sfr...@snowman.net> wrote: > I'm also of the opinion that this isn't strictly necessary for the > initial RLS offering in PG- there's a clear way we could migrate > existing users to a multi-policy system from a single-policy system. > Sure, to get the performance and optimization benefits that we'd > presumably have in the multi-policy case they'd need to re-work their > RLS configuration, but for users who care, they'll likely be very happy > to do so to gain those benefits.
I think a lot depends on the syntax we choose. If we choose a syntax that only makes sense in a single-policy framework, then I think allowing upgrades to a multi-policy syntax is going to be really difficult. On the other hand, if we choose a syntax that allows multiple policies, I suspect we can support multiple policies from the beginning without much extra effort. >> - Require the user to specify in some way which of the available >> policies they want applied, and then apply only that one. > > I'd want to at least see a way to apply an ordering to the policies > being applied, or have PG work out which one is "cheapest" and try that > one first. Cost-based comparison of policies that return different results doesn't seem sensible to me. >> I think exactly the opposite, for the query planning reasons >> previously stated. I think the policies will quickly get so >> complicated that they're no longer optimizable. Here's a simple >> example: >> >> - Policy 1 allows the user to access rows for which complexfunc() returns >> true. >> - Policy 2 allows the user to access rows for which a = 1. >> >> Most users have access only through policy 2, but some have access >> through policy 1. Users who have access through policy 1 will always >> get a sequential scan, > > This is the thing which I most object to- if the quals being provided at > any level are leakproof and would be able to reduce the returned set > sufficiently that an index scan is the best bet, we should be doing > that. I don't anticipate the RLS quals to be as selective as the > quals which the user is adding. I think it would be a VERY bad idea to design the system around the assumption that the RLS quals will be much more or less selective than the user-supplied quals. That's going to be different in different environments. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
