On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote: > On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Noah Misch <n...@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.
pgp5nMdr7L0Ul.pgp
Description: PGP signature
