Re: CREATEROLE and role ownership hierarchies

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATEROLE and role ownership hierarchies
Date: 2021-10-26 18:50:49
Message-ID: b4e5913b-e0a7-c48f-b419-ac3b7e26dda1@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/21/21 19:21, Mark Dilger wrote:
>> Also, are we just going to strip
>> the current CREATEROLE roles of much of their powers? Maybe it's
>> worth keeping a legacy CREATEROLE role attribute for upgraded clusters
>> that could eventually be removed down the road.
> The patch as written drastically reduces the power of the CREATEROLE attribute, in a non-backwards compatible way. I wondered if there would be complaints about that. If so, we could instead leave CREATEROLE alone, and create some other privileged role for the same thing, but it does start to look funny having a CREATEROLE privilege bit and also a privileged role named, perhaps, pg_can_create_roles.

Give that CREATEROLE currently just about amounts to being a superuser,
maybe there should be a pg_upgrade option to convert CREATEROLE to
SUPERUSER. I don't want to perpetuate the misfeature though, so let's
just bring it to an end.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-10-26 18:58:31 Re: src/port/snprintf.c: Optimize the common base=10 case in fmtint
Previous Message Tom Lane 2021-10-26 18:33:08 Re: src/port/snprintf.c: Optimize the common base=10 case in fmtint