Re: predefined role(s) for VACUUM and ANALYZE

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: predefined role(s) for VACUUM and ANALYZE
Дата
Msg-id CA+Tgmoa7jS1uvq2s+GLWbCT6e1wH2thfSBHbsF88rtg+Dd4PaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: predefined role(s) for VACUUM and ANALYZE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: predefined role(s) for VACUUM and ANALYZE  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: predefined role(s) for VACUUM and ANALYZE  (Nathan Bossart <nathandbossart@gmail.com>)
Re: predefined role(s) for VACUUM and ANALYZE  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Tue, Jul 26, 2022 at 1:50 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>> Still, it seems somewhat appealing to give
>> people fine-grained control over this, rather than just "on" or "off".
> Appealing enough to consume a couple of permission bits?
> https://www.postgresql.org/message-id/CAKFQuwZ6dhjTFV7Bwmehe1N3%3Dk484y4mM22zuYjVEU2dq9V1aQ%40mail.gmail.com

I think we're down to 0 remaining now, so it'd be hard to justify
consuming 2 of 0 remaining bits. However, I maintain that the solution
to this is either (1) change the aclitem representation to get another
32 bits or (2) invent a different system for less-commonly used
permission bits. Checking permissions for SELECT or UPDATE has to be
really fast, because most queries will need to do that sort of thing.
If we represented VACUUM or ANALYZE in some other way in the catalogs
that was more scalable but less efficient, it wouldn't be a big deal
(although there's the issue of code duplication to consider).

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Transparent column encryption
Следующее
От: vignesh C
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup