Re: Have REFRESH MATERIALIZED VIEW run as the MV owner
От | Hitoshi Harada |
---|---|
Тема | Re: Have REFRESH MATERIALIZED VIEW run as the MV owner |
Дата | |
Msg-id | CAP7Qgmmh3n36bRgFbER0j4AZ4v96=F0rb7TCT1aiP3XnwJk=8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Have REFRESH MATERIALIZED VIEW run as the MV owner (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Have REFRESH MATERIALIZED VIEW run as the MV owner
|
Список | pgsql-hackers |
On Fri, Jul 5, 2013 at 9:45 AM, Noah Misch <noah@leadboat.com> wrote: > 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. I was trying to understand why this is safe for a while. REINDEX and VACUUM make sense to me because they never contain side-effect as far as I know, but MV can contain some volatile functions which could have some unintended operation that shouldn't be invoked by no one but the owner. For example, if the function creates a permanent table per call and doesn't clean it up, but later some other maintenance operation is supposed to clean it up, and the owner schedules REFRESH and maintenance once a day. A non-owner user now can refresh it so many times until the disk gets full. Or is that operation supposed to be restricted by the security context you are adding? -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: