Greetings,
* Nathan Bossart (nathandbossart@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
