Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 28, 2018 at 9:56 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> I made an argument for an "ANALYZE" grant a little while back, and it kinda
>> leads one to want one for VACUUM as well.
> Yeah, and FWIW, I think that's a totally reasonable request, as is
> this one. The problem is that our authentication model seems to have
> been designed under the assumption that there weren't all that many
> different things you might want to separately GRANT, and the requests
> we've had over the years show that this isn't the case. So the
> request is reasonable; it's just hard to implement. I think we should
> somehow move to a system where there's a set of "core" permissions
> that are identified by bits for efficiency, and a set of "extended"
> permissions which are identified by names for extensibility. Things
> like VACUUM and ANALYZE and REFRESH could be extended permissions.
That seems like an awful lot of work to handle what's still going to be
a pretty small set of permissions. Every permission we add is going to
have to be enforced in the C code, and it'll break applications to some
extent to treat the situation differently from before, so I don't see
that we're going to add them willy-nilly.
(For what it's worth, my first instinct would be to lump all three of
these proposals under a single grantable permission MAINTAIN, or some
such name. I don't think it's worth subdividing more finely.)
> To handle the on-disk issue, I think we could introduce a new varlena
> type that's like aclitem but permits extra variable-length data at the
> end. It would be a different data type but pretty easy to convert
> back and forth. Still probably a lot of work to make it happen,
> though, unfortunately.
I think an appropriate amount of effort would be to widen AclMode to 64
bits, which wasn't practical back in the day but now we could do easily
(I think). That would move us from having four spare permission bits
to having 20. I don't think it'd cause an on-disk compatibility break
because type aclitem is generally only stored in the catalogs anyway.
regards, tom lane
