So, I will split the patch into two parts as follows, in the next commit fest.
Part-1) Views with security_barrier reloption The part-1 portion provides views "security_barrier" reloption; that enables to keep sub-queries unflatten in the prepjoin.c stage. In addition, these sub-queries (that originally come from views with "security_barrier" option) don't allow to push down qualifiers from upper level. It shall prevent both of the problematic scenarios. Part-2) Functions with leakproof attribute The part-2 portion provides functions "leakproof" attribute; that enables to push down leakproof functions into sub-queries, even if it originally come from security views. It shall minimize performance damages when we use view for row-level security purpose. 2011/10/19 Tom Lane <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@gmail.com> writes: >> Well, there's clearly some way to prevent pushdown from happening, >> because sticking a LIMIT in there does the trick... > > I already pointed you at subquery_is_pushdown_safe ... > > regards, tom lane > -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
