Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers