Re: [v9.2] Fix Leaky View Problem

Robert Haas <robertmhaas@gmail.com> writes:
> Having looked at this more, I'm starting to believe KaiGai has this
> part right after all.

Yeah, you have a point.  The rewriter is intentionally trying to make an
expanded view look just the same as an in-line SELECT-in-FROM, and we
need it to be easier to distinguish them.

> 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.
        regards, tom lane