Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Tue, Aug 23, 2022 at 07:46:47PM -0400, Stephen Frost wrote: > > I've long felt that we should redefine the way the ACLs work to have a > > distinct set of bits for each object type. We don't need to support a > > CONNECT bit on a table, yet we do today and we expend quite a few bits > > in that way. Having that handled on a per-object-type basis instead > > would allow us to get quite a bit more mileage out of the existing 32bit > > field before having to introduce more complicated storage methods like > > using a bit to tell us to go look up more ACLs somewhere else. > > 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.
Considering our burn rate of ACL bits is really rather slow (2 this year, but prior to that was TRUNCATE in 2008 and CONNECT in 2006), I'd argue that moving away from the current one-size-fits-all situation would kick the can down the road more than just 'a little' and wouldn't have any performance or space concerns. Once we actually get to the point where we've burned through all of those after the next few decades then we can move to a uint64 or something else more complicated, perhaps. If we were to make the specific bits depend on the object type as I'm suggesting, then we'd have 8 bits used for relations (10 with the vacuum and analyze bits), leaving us with 6 remaining inside the existing uint32, or more bits available than we've ever used since the original implementation from what I can tell, or at least 15+ years. That seems like pretty darn good future-proofing without a lot of complication or any change in physical size. We would also be able to get rid of the question of "well, is it more valuable to add the ability to GRANT TRUNCATE on a relation, or GRANT CONNECT on databases" or other rather odd debates between ultimately very different things. Thanks, Stephen
signature.asc
Description: PGP signature