* Peter Eisentraut ( 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:

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.



Attachment: signature.asc
Description: Digital signature

Reply via email to