Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
От | Bossart, Nathan |
---|---|
Тема | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
Дата | |
Msg-id | 8B7DFC0A-9CF9-4620-9FDD-D1A4C8269B68@amazon.com обсуждение исходный текст |
Ответ на | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
|
Список | pgsql-hackers |
On 11/1/21, 9:51 AM, "Stephen Frost" <sfrost@snowman.net> wrote: > I don't really buy off on the "because it's been around a long time" as > a reason to invent a predefined role for an individual command that > doesn't take any options and could certainly just be a function. > Applications developed to run as a superuser aren't likely to magically > start working because they were GRANT'd this one additional predefined > role either but likely would need other changes anyway. I suspect the CHECKPOINT command wouldn't be removed anytime soon, either. I definitely understand the desire to avoid changing something that's been around a long time, but I think a function fits better in this case. > All that said, I wonder if we can have our cake and eat it too. I > haven't looked into this at all yet and perhaps it's foolish on its > face, but, could we make CHECKPOINT; basically turn around and just run > select pg_checkpoint(); with the regular privilege checking happening? > Then we'd keep the existing syntax working, but if the user is allowed > to run the command would depend on if they've been GRANT'd EXECUTE > rights on the function or not. I'd be worried about the behavior of CHECKPOINT changing because someone messed with the function. Nathan
В списке pgsql-hackers по дате отправления: