On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane <tgl@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
