* 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
Description: Digital signature