Re: [HACKERS] logical replication access control patches - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] logical replication access control patches
Date
Msg-id 7fb8b6be-8a6f-4124-f462-e7ce0ca78a24@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication access control patches  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] logical replication access control patches  (Stephen Frost <sfrost@snowman.net>)
List 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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Proposal : Parallel Merge Join
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] DROP FUNCTION of multiple functions