On Tue, May 15, 2018 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.)
That's certainly a fair opinion, but I'm just not sure whether users
are going to agree.
>> 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.
How much are we worried about users (or extensions) who have used it
in user tables? We could introduce aclitem2 and keep the old one
around, I guess.
If we're going to go to the trouble of making an incompatible change
to aclitem, it seems like we should go all the way and make it into
some kind of varlena type. Realistically, if we add another 32 bits
to it, you're going to let 3 or 4 new permissions through -- max --
and then go back to worrying about how many bits we have left and how
quickly we're eating them up. I guess if somebody else is doing the
work I'll be content to let them do it how they want to do it, but if
I were doing the work, I would look for a bigger hammer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
