Re: BUG #13907: Restore materialized view throw permission denied

On Tue, Jul 26, 2016 at 10:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
>> The problem we're having restoring the matview state is that not
>> all ACLs needed for *SELECT* permissions are in place in time. I
>> am not seeing the problem with self-revoke on REFRESH. What am I
>> missing?
>
> 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? If I'm understanding what you want, the only way to get
that would be to COPY matview data the same as a table, and have a
way to load it in before locking down the matview from direct
changes. That seems to me like it would completely compromise
future ability to incrementally maintain matviews, since you could
not have any assurance that the state of a matview matched any
particular derivation from the sources, matched to a point where
changes could be played forward.

>> One other question about the patch was what I did for testing. It
>> seemed like a good idea to have dump/restore tests, but I don't see
>> how to do that without leaving a role or two lingering in the
>> cluster. Is that allowed?
>
> In make installcheck, no, it is absolutely not. I'd suggest thinking
> about testing this in the pg_dump TAP tests, instead, where we're just
> creating a private database instance.

ok

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company