2011/9/26 Tom Lane <t...@sss.pgh.pa.us>: > Kohei KaiGai <kai...@kaigai.gr.jp> writes: >> Sorry, are you saying the current (in other words, rte->security_barrier >> stores the state of reloption) approach is not a good idea? > > Yes. I think the same as Robert: the way to handle this is to store it > in RelOptInfo for the duration of planning, and pull it from the > catalogs during planner startup (cf plancat.c). > Hmm. If so, it seems to me worthwhile to investigate an alternative approach that stores relation-id of the view on rte->relid if rtekind is RTE_SUBQUERY and pull the "security_barrier" flag from the catalog during planner stage.
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
