From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: predefined role(s) for VACUUM and ANALYZE |
Date: | 2022-09-06 12:26:55 |
Message-ID: | CA+TgmoZDywqeA3Audb3=oCeXB6rwKuCjmPtawSpS5y1g1ohgew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 5, 2022 at 2:56 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> There are 2 bits remaining at the moment, so I didn't redesign the ACL
> system in the attached patch. However, I did some research on a couple
> options. Using a distinct set of bits for each catalog table should free
> up a handful of bits, which should indeed kick the can down the road a
> little. Another easy option is to simply make AclMode a uint64, which
> would immediately free up another 16 privilege bits. I was able to get
> this approach building and passing tests in a few minutes, but there might
> be performance/space concerns.
I believe Tom has expressed such concerns in the past, but it is not
clear to me that they are well-founded. I don't think we have much
code that manipulates large numbers of aclitems, so I can't quite see
where the larger size would be an issue. There may well be some
places, so I'm not saying that Tom or anyone else with concerns is
wrong, but I'm just having a hard time thinking of where it would be a
real issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2022-09-06 12:29:22 | Re: HOT chain validation in verify_heapam() |
Previous Message | Christoph Berg | 2022-09-06 12:25:26 | psql -l and locales (Re: pgsql: Add option to use ICU as global locale provider) |