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