From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical replication access control patches |
Date: | 2017-02-25 13:24:13 |
Message-ID: | 7fb8b6be-8a6f-4124-f462-e7ce0ca78a24@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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'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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-02-25 13:27:53 | Re: DROP FUNCTION of multiple functions |
Previous Message | Amit Kapila | 2017-02-25 12:37:48 | Re: Proposal : Parallel Merge Join |