Re: Re: BUG #6264: Superuser does not have inherent Replication permission

On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Noah Misch <noah(at)leadboat(dot)com> writes:
> >> Let's look at the behavior of DDL-exposed access constraints for precedent. ?We
> >> currently have three paradigms for applying access control to superusers:
> >
> >> 1. Settings that affect superusers and regular users identically. ?These include
> >> ALTER ROLE ... LOGIN | VALID UNTIL.
> >
> >> 2. Rights that superusers possess implicitly and irrevocably; the actual setting
> >> recorded in pg_authid or elsewhere has no effect. ?These include GRANT ... ON
> >> TABLE and ALTER ROLE ... CREATEDB | CREATEROLE.
> >
> >> 3. ALTER ROLE ... REPLICATION is very similar to #1, except that CREATE ROLE
> >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
> >
> >> I think we should merge #3 into #2; nothing about the REPLICATION setting
> >> justifies a distinct paradigm.
> >
> > Yeah, there's much to be said for that. ?I thought the notion of a
> > privilege that superusers might not have was pretty bogus to start with.

> That seems fine for 9.2, but I am still not in favor of changing the
> behavior in back branches. This is not such a confusing behavior that
> we can't document our way out of it.
>
> (Hey, if SELECT .. ORDER BY .. FOR UPDATE can return rows out of order
> and we can document our way out of that, this is small potatoes by
> comparison.)

Quite so. Let's do it that way.