| 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 15:13:54 |
| Message-ID: | 17767.1469546034@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:
> 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?
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-07-26 16:39:21 | Re: BUG #13907: Restore materialized view throw permission denied |
| Previous Message | Kevin Grittner | 2016-07-26 14:21:24 | Re: BUG #13907: Restore materialized view throw permission denied |