Re: logical replication access control patches

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

In response to

Responses

Browse pgsql-hackers by date

  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