On Sat, Jan 14, 2012 at 06:34:25PM +0200, Heikki Linnakangas wrote: > On 02.01.2012 21:46, Noah Misch wrote: >> 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<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. >> >> Patch attached. > > Thanks, committed to master.
Thanks. > Was there something that still needed to be done for the 9.1 docs? I'm > not sure what the conclusion on that was in the discussions back in > October. Not that I noted. The former docs describe the 9.1 behavior thoroughly. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
