Horton

Re: CREATEROLE and role ownership hierarchies

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Shinya Kato <Shinya11.Kato@oss.nttdata.com>, "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-28T16:14:06Z
Lists: pgsql-hackers 
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.

			regards, tom lane

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