Have REFRESH MATERIALIZED VIEW run as the MV owner

From: Noah Misch <noah(at)leadboat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: kgrittn(at)ymail(dot)com
Subject: Have REFRESH MATERIALIZED VIEW run as the MV owner
Date: 2013-07-05 16:45:51
Message-ID: 20130705164551.GA1059784@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

REFRESH MATERIALIZED VIEW should temporarily switch the current user ID to the
MV owner. REINDEX and VACUUM do so to let privileged users safely maintain
objects owned by others, and REFRESH MATERIALIZED VIEW belongs in that class
of commands. The MV query then runs as a "security-restricted operation",
which forbids a few commands. Most, e.g. UNLISTEN, are unlikely to arise in
practice. The most interesting restriction is probably CREATE TEMP TABLE.
Consider a function that creates and later drops a temporary table that it
uses for intermediate storage during a complicated calculation. That function
will no longer work in a MV query. As a workaround, modify the function to
use a permanent table as its work area.

See attached patch. The similar behavior of REINDEX et al. is undocumented.
Users are a bit more likely to notice limitations in the context of MVs, so I
added a brief documentation mention. Seeing that this narrows the range of
valid MV queries, I bring it up now so MVs can debut with the restrictions
already in place.

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

Attachment Content-Type Size
matview-secure-refresh-v1.patch text/plain 4.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-07-05 17:04:12 Re: strange IS NULL behaviour
Previous Message Tom Lane 2013-07-05 16:43:57 Re: strange IS NULL behaviour