On Wed, Dec 7, 2011 at 1:45 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
