On 19 May 2018 at 01:13, Stephen Frost <sfr...@snowman.net> wrote: > > I'm not entirely sure about the varlena suggestion, seems like that > would change a great deal more code and be slower, though perhaps not > enough to matter; it's not like our aclitem arrays are exactly optimized > for speed today.
I don't actually understand the reason y'all are talking about varlena. The aclitem type is already not passbyvalue so there's no particular limit on the size and specifically no reason it can't be larger than 64 bytes. As Tom mentioned it's only used in catalogs so there's no on-disk version compatibility issue either. It can be defined to have a bitmask exactly large enough to hold all the acl privileges needed for the specific version and still not be a varlena. The only downsides are: 1. At some point it gets large enough that adding rarely used privileges is imposing a large storage and cache efficiency cost that's amortized over all the acl lookups even when it's not used. I doubt we're anywhere close to that currently but if we started having hundreds of privileges... 2. The current macros just do a bitshift to look up bits and they would get a bit more complex. But it's not like it isn't arithmetic we haven't tackled repeatedly in other places that do bitmasks such as varbit, numeric, bitmapset, and probably more. Fwiw I don't understand why the current AclMode uses a single uint32 to pass around two 16-bit bitmasks and uses bitshifting to extract the two. Why not just make it a struct with two uint16s in it instead? That would mean we would have a factor of four available before the macros even get the slight added complication. -- greg
