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 precede=
nt. =A0We
>> currently have three paradigms for applying access control to superusers:
>
>> 1. Settings that affect superusers and regular users identically. =A0The=
se 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. =A0These 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. =A0I thought the notion of a
> privilege that superusers might not have was pretty bogus to start with.
>
> rolcatupdate isn't a very good precedent to rely on because it's never
> been documented or used to any noticeable extent, so there's no reason
> to think that it provides a tested-and-accepted behavior.
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.)
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
