Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2/18/17 18:06, Stephen Frost wrote: > > I'm not convinced that it really makes sense to have PUBLICATION of a > > table be independent from the rights an owner of a table has. We don't > > allow other ALTER commands on objects based on GRANT'able rights, in > > general, so I'm not really sure that it makes sense to do so here. > > The REFERENCES and TRIGGER privileges are very similar in principle.
TRIGGER is a great example of an, ultimately, poorly chosen privilege to GRANT away, with a good history of discussion about it: https://www.postgresql.org/message-id/21827.1166115978%40sss.pgh.pa.us https://www.postgresql.org/message-id/7389.1405554356%40sss.pgh.pa.us Further, how would RLS be handled with publication? I've been assuming that it's simply ignored, but that's clearly wrong if a non-owner can publish a table that they just have SELECT,PUBLISH on, isn't it? > > The downside of adding these privileges is that we're burning through > > the last few bits in the ACLMASK for a privilege that doesn't really > > seem like it's something that would be GRANT'd in general usage. > > I don't see any reason why we couldn't increase the size of AclMode if > it becomes necessary. I've fought exactly that argument before and there is a good deal of entirely reasonable push-back on increasing our catalogs by so much. > > I'm certainly all for removing the need for users to be the superuser > > for such commands, just not sure that they should be GRANT'able > > privileges instead of privileges which the owner of the relation or > > database has. > > Then you couldn't set up a replication structure involving tables owned > by different users without resorting to blunt instruments like having > everything owned by the same user or using superusers. That's not correct- you would simply need a user who is considered an owner for all of the objects which you want to replicate, that doesn't have to be a *direct* owner or a superuser. The tables can have individual roles, with some admin role who is a member of those other roles, or another mechanism (as Simon has proposed not too long ago...) to have a given role be considered equivilant to an owner for all of the relations in a particular database. Thanks! Stephen
signature.asc
Description: Digital signature
