| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [v9.2] Fix Leaky View Problem |
| Date: | 2011-09-26 18:37:26 |
| Message-ID: | CA+Tgmobc0i4n+-GCXesai7ft49_beWRYXapTJ0HNOZtP2uhcjw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-09-26 18:38:32 | Re: Support UTF-8 files with BOM in COPY FROM |
| Previous Message | Peter Eisentraut | 2011-09-26 18:35:53 | Re: Support UTF-8 files with BOM in COPY FROM |