* Tom Lane (t...@sss.pgh.pa.us) wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: > > I agree, and now that the urgency of trying to deliver this for 9.4 is > > over it's worth seeing if we can just run as table owner. > > > Failing that, we could take the approach a certain other RDBMS does and > > make the ability to define row security quals a GRANTable right > > initially held only by the superuser. > > Hmm ... that might be a workable compromise. I think the main issue here > is whether we expect that RLS quals will be something that the planner > could optimize to any meaningful extent. If they're always (in effect) > wrapped in SECURITY DEFINER functions, I think that largely blocks any > optimizations; but maybe that wouldn't matter in practice.
From what I've heard from actual users with other RDBMS's who are coming
to PostgreSQL- the reality is that they're going to be using a security
module (eg: SELinux) whose responsibility it is to manage this whole
question of "can this user see this row", meaning there's zero chance of
optimization.
I'd certainly like to see the ability to optimize remain in cases where
the qual itself gives us a way to filter (eg: a table partitioned based
on some security level, where another table maps users to levels), but
that is, from a practical standpoint, not an immediate concern from real
users and I don't believe our approach paints us into a corner which
would prevent that. What that would require is better support for true
partitioning rather than constraint exclusions.
Thanks,
Stephen
signature.asc
Description: Digital signature
