On Fri, Oct 28, 2011 at 11:42:38AM -0400, Noah Misch wrote:
> 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@sss.pgh.pa.us> wrote:
> > > Noah Misch <noah@leadboat.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.
Patch attached.
