Re: [v9.2] Fix Leaky View Problem

On Wed, Dec 7, 2011 at 1:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> One other possibility that comes to mind is that, instead of adding
>> "bool security_view" to the RTE, we could instead add a new RTEKind,
>> something like RTE_SECURITY_VIEW.  That would mean going through and
>> finding all the places that refer to RTE_SUBQUERY and adjusting them
>> to handle RTE_SECURITY_VIEW in either the same way or differently as
>> may be appropriate.  The possible advantage of this approach is that
>> it doesn't bloat the RTE structure (and stored rules that use it) with
>> an additional attribute that (I think) will always be false - because
>> security_barrier can only be set on a subquery RTE after rewriting has
>> happened, and stored rules are haven't been rewritten yet.  It might
>> also force people to think a bit more carefully about how security
>> views should be handled during future code changes, which could also
>> be viewed as a plus.
>
> Hmm.  The question is whether the places where we need to care about
> this would naturally be looking at RTEKind anyway.  If they are, or many
> are, then I think this might be a good idea.  However if a lot of the
> action is elsewhere then I don't know if we get much leverage from the
> new RTEKind.  I haven't read the patch lately so can't opine on that.

*reads through the code*

It looks to me like most places that look at RTE_SUBQUERY really have
no reason to care about this. So probably it's just as well to have a
separate flag for it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company