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<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.
>
> 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.
