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? -- 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
