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

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:

Reply via email to