| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yebhavinga(at)gmail(dot)com> |
| Subject: | Re: Row-security on updatable s.b. views |
| Date: | 2014-02-07 01:41:02 |
| Message-ID: | 52F439AE.8000808@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02/06/2014 11:11 PM, Tom Lane wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>> We don't rerun rewrite on plan invalidation.
>
> Don't we? plancache.c certainly does, in fact it starts from the raw
> grammar output. Skipping the rewriter would mean failing to respond
> to CREATE OR REPLACE VIEW, for example.
I was thinking about exactly that case as I went to sleep - especially
as it's things like CREATE OR REPLACE VIEW that prevent me from just
rewriting the security qual when it's initially added, before storage in
the catalogs.
I could've sworn discussion around row security in the past concluded
that it couldn't be properly done in the rewriter because of an
inability to correctly invalidate plans. Searching the archives, though,
I don't find anything to support that. I'll just say I'm glad to be
wrong, and proceed from there.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2014-02-07 03:25:35 | Re: narwhal and PGDLLIMPORT |
| Previous Message | Tom Lane | 2014-02-07 01:06:03 | Re: Recovery inconsistencies, standby much larger than primary |