Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, Jun 18, 2014 at 10:40 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Robert Haas (robertmhaas@gmail.com) wrote:
> >> Technically, there are 4 bits left, and that's what we need for
> >> separate privileges.
> >
> > I'd really hate to chew them all up..
>
> Usually it's the patch author who WANTS to chew up all the available
> bit space and OTHER people who say no. :-)
Ah, well, technically I'm not the patch author here, though I would like
to see it happen. :) Still, have to balance these features and
capabilities against the future unknown options we might want to add and
it certainly doesn't seem terribly nice to chew up all that remain
rather than addressing the need to support more.
Still, perhaps we can put together a patch for this and then review the
implementation and, if we like it and that functionality, we can make
the decision about if it should be on this patch to make more bits
available.
> > Perhaps, or we might come up with some new whiz-bang permission to add
> > next year. :/
>
> Well, people proposed separate permissions for things like VACUUM and
> ANALYZE around the time TRUNCATE was added, and those were rejected on
> the grounds that they didn't add enough value to justify wasting bits
> on them. I think we see whether there's a workable system that such
> that marginal permissions (like TRUNCATE) that won't be checked often
> don't have to consume bits.
That's an interesting approach but I'm not sure that we need to go a
system where we segregate "often-used" bits from "less-used" ones.
> > My thoughts on how to address this were to segregate the ACL bits by
> > object type. That is to say, the AclMode stored for databases might
> > only use bits 0-2 (create/connect/temporary), while tables would use
> > bits 0-7 (insert/select/update/delete/references/trigger). This would
> > allow us to more easily add more rights at the database and/or
> > tablespace level too.
>
> Yeah, that's another idea. But it really deserves its own thread.
> I'm still not convinced we have to do this at all to meet this need,
> but that should be argued back and forth on that other thread.
Fair enough.
Thanks,
Stephen
