Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view

>
> > test=# REFRESH MATERIALIZED VIEW CONCURRENTLY test_mv;
> > ERROR: permission denied for table test
> > --what??? N1
> >
> > --check that im not hallucinating
> > test=# select * from test;
> > val
> > -----
> > 1
> > (1 row)
>
> So far, this is working correctly. REFRESH MATERIALIZED VIEW runs with
> the permissions of the materialized view's owner. In this case, the
> owner is 'test_role', which doesn't have select permission on the table.
>

This decision led to a strange (and only one known to me) case when a
superuser cannot do something in the database.
(so far I have yet to see any other possible scenario when a command run by
superuser fails with permission error).

May I suggest a change to always allow superuser run REFRESH MATERIALIZED
VIEW (may be via set role or similar mechanics)?

Without that I think it's possible build a case of the database which could
be dumped but cannot be restored without errors
(restore from MV owner cannot be done because dump contains create
extension (for a sample) and restore from superuser cannot be done because
refresh MV permission check).

--
Maxim Boguk
Senior Postgresql DBA

Phone UA: +380 99 143 0000
Phone AU: +61 45 218 5678