2011/9/26 Robert Haas <robertmh...@gmail.com>: > On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>> I think it is. If you create a view that involves an RTE, the node >>> tree is going to get stored in pg_rewrite.ev_action. And it's going >>> to include the security_barrier attribute, because you added outfuncs >>> support for it... >>> >>> No? >>> >> IIUC, nested views are also expanded when user's query gets rewritten. >> Thus, rte->security_barrier shall be set based on the latest configuration >> of the view. >> I injected an elog(NOTICE, ...) to confirm the behavior, when >> security_barrier >> flag was set on rte->security_barrier at ApplyRetrieveRule(). > > Hmm, OK. I am still not convinced that this is the right approach. > Normally, we don't cache anything in the RangeTblEntry that might > change between plan time and execution time. Those things are > normally stored in the RelOptInfo - why not do the same here? > The point is that a sub-query come from a particular view does not keep the information what view originally stored the sub-query when it was passed to the executor stage. PostgreSQL handles a view as just a sub-query after the rewriter stage.
One possible idea not to store the flag in RangeTblEntry is to utilize rte->relid to show the relation-id of the source view, when rtekind is RTE_SUBQUERY; that enables to pull the security_barrier flag in executor stage. However, the interface to reference reloptions are designed to pull this information with Relation pointer, rather than lsyscache, so I implemented this revision with a new rte->security_barrier member. Thanks, -- 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
