Horton

Re: CREATEROLE and role ownership hierarchies

Shinya Kato <shinya11.kato@oss.nttdata.com>

View thread View on postgr.es
From: Shinya Kato <Shinya11.Kato@oss.nttdata.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Mark Dilger <mark.dilger@enterprisedb.com>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Jeff Davis <pgsql@j-davis.com>
Date: 2021-10-29T02:05:10Z
Lists: pgsql-hackers 
On 2021-10-29 01:14, Tom Lane wrote:
> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> The only intentional backward compatibility break in this patch set is 
>> the the behavior of CREATEROLE.  The general hope is that such a 
>> compatibility break will help far more than it hurts, as CREATEROLE 
>> does not appear to be a well adopted feature.  I would expect that 
>> breaking the behavior of the WITH ADMIN OPTION feature would cause a 
>> lot more pain.
> 
> Even more to the point, WITH ADMIN OPTION is defined by the SQL 
> standard.
> The only way you get to mess with that is if you can convince people we
> mis-implemented the standard.
Thank you for the detailed explanation.
I now understand what you said.

-- 
Regards,

--
Shinya Kato
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

Commits

  1. Make role grant system more consistent with other privileges.

  2. Ensure that pg_auth_members.grantor is always valid.

  3. Remove the ability of a role to administer itself.

  4. Add tests of the CREATEROLE attribute

  5. Replace explicit PIN entries in pg_depend with an OID range test.

  6. Shore up ADMIN OPTION restrictions.

  7. Add pg_has_role() family of privilege inquiry functions modeled after the

  8. Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion