Re: predefined role(s) for VACUUM and ANALYZE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: predefined role(s) for VACUUM and ANALYZE
Date
Msg-id CA+Tgmoa7jS1uvq2s+GLWbCT6e1wH2thfSBHbsF88rtg+Dd4PaQ@mail.gmail.com
Whole thread Raw
In response to Re: predefined role(s) for VACUUM and ANALYZE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: predefined role(s) for VACUUM and ANALYZE
Re: predefined role(s) for VACUUM and ANALYZE
Re: predefined role(s) for VACUUM and ANALYZE
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Transparent column encryption
Next
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup