| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, marian(dot)krucina(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #13907: Restore materialized view throw permission denied |
| Date: | 2016-07-26 13:54:10 |
| Message-ID: | 5850.1469541250@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> So you are suggesting that restoring from pg_dump output should
> generate materialized view data under a different security context
> than would be used by a REFRESH statement on the source database?
Yes. Consider the following simple example (done by a non-superuser
named joe):
create table joes_table(f1 int);
insert into joes_table values(1);
revoke insert on joes_table from joe;
pg_dump is required to be able to restore the state of this table
correctly. It will fail to do so if it issues the revoke before
loading data. The same issue applies to all data loading,
including refreshing matviews.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-07-26 14:21:24 | Re: BUG #13907: Restore materialized view throw permission denied |
| Previous Message | daeli | 2016-07-26 12:24:49 | BUG #14264: Error installing 9.6 beta 3 on Red hat 6.5 |