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 17:32:47 |
Message-ID: | 26375.1469554367@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:
> On Tue, Jul 26, 2016 at 10:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Uh ... that the owner might revoke his own SELECT privilege?
> What about policies that might have changed since the latest
> REFRESH before dump? How about views or functions that might have
> changed?
I think you're setting up straw men. No one has argued that we should
dump and restore the verbatim current contents of a matview. But there
is a longstanding expectation that pg_dump be able to dump and restore
the contents of read-only tables, and what you proposed breaks that.
That won't do.
It's possible that the most reasonable fix is to move matview refreshes to
after the ACL restoration step. That would wreak a lot of havoc with
the current view of a dump as being tripartite (pre-data/data/post-data),
so it might be more work than we want to do. But it seems like the
logically soundest thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-07-26 17:44:15 | Re: BUG #13907: Restore materialized view throw permission denied |
Previous Message | Kevin Grittner | 2016-07-26 16:39:21 | Re: BUG #13907: Restore materialized view throw permission denied |