Have REFRESH MATERIALIZED VIEW run as the MV owner
Вложения
В списке pgsql-hackers по дате отправления:
| От | Noah Misch |
|---|---|
| Тема | Have REFRESH MATERIALIZED VIEW run as the MV owner |
| Дата | |
| Msg-id | 20130705164551.GA1059784@tornado.leadboat.com обсуждение исходный текст |
| Ответы |
Re: Have REFRESH MATERIALIZED VIEW run as the MV owner
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера