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