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 prece=
dent. ?We
> >> currently have three paradigms for applying access control to superuse=
rs:
> >
> >> 1. Settings that affect superusers and regular users identically. ?The=
se include
> >> ALTER ROLE ... LOGIN | VALID UNTIL.
> >
> >> 2. Rights that superusers possess implicitly and irrevocably; the actu=
al 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 CREAT=
E ROLE
> >> ... SUPERUSER implies CREATE ROLE ... SUPERUSER REPLICATION.
> >
> >> I think we should merge #3 into #2; nothing about the REPLICATION sett=
ing
> >> 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.
>=20
> (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.
