On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Well, the security-barrier view stuff did not present itself as a 100% > solution. But perhaps more to the point, it was conceptually simple to > implement, ie don't flatten views if they have this bit set, and don't > push down quals into such sub-selects unless they're marked leakproof.
Right. IMHO, this new feature should be similarly simple: when an unprivileged user references a table, treat that as a reference to a leakproof view over the table, with the RLS qual injected into the view. >> I haven't reviewed this patch in a long time, but I would >> expect that it's basically just reusing that same infrastructure; in >> fact, I'd expect that it's little more than syntactic sugar around >> that infrastructure. > > I've not read it in great detail, but it isn't that. It's whacking the > planner around in ways that I have no confidence in, and probably still > wouldn't have any confidence in if they'd been adequately documented. If that's the case, then I agree that we should not accept it, at least in its present form. -- 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
