On Tue, Oct 7, 2014 at 9:55 AM, Stephen Frost <sfrost@snowman.net> wrote:
> ... or you could just only have one policy on the table and do whatever
> you'd like with it (which was the original idea, actually, though I've
> found myself very much liking the ability to have multiple policies, and
> to have them set for specific roles and commands, rather than having to
> have one very complicated policy or having to use a function..).
The key point from my angle is that if you grant user alice the right
to see records where a = 1 and user bob the right to see records where
a = 2, the multiple-policy approach allows those quals to be
implemented as index-scans. If you had a single policy granting all
users the right to see records where policyfunc() returns true, it
would never be indexable.
I think that Thom's idea of having some policies that are additional
filter conditions on top of everything else is a pretty good one.
It's probably possible to construct a case where you need multiple
levels of AND and OR logic, which Thom's proposal does not provide
for. But are there really cases like that which anyone cares about?
I think we're going to be tempted to think about that question for
about 60 seconds and say "nope", and that's probably not enough
thought. It deserves serious reflection, because I think Thom's
proposal is terminal: if we do what he's proposing, it'll be hard to
extend the idea any further if we later discover that it isn't general
enough. That having been said, what he's proposing is simple and
covers a fair amount of ground, and is thus worthy of serious
consideration, at least IMHO.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
