On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost <sfrost@snowman.net> wrote:
> 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.
Our burn rate is slow because there's been a lot of pushback - mostly
from Tom - about consuming the remaining bits. It's not because people
haven't had ideas about how to use them up.
> 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.
I mostly agree with this. I don't think it's entirely clear how we
should try to get more bits going forward, but it's clear that we
cannot just forever hold our breath and refuse to find any more bits.
And of the possible ways of doing it, this seems like the one with the
lowest impact, so I think it likely makes sense to do this one first.
--
Robert Haas
EDB: http://www.enterprisedb.com