Horton

Re: fixing CREATEROLE

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Mark Dilger <mark.dilger@enterprisedb.com>, "walther@technowledgy.de" <walther@technowledgy.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2025-05-05T15:23:05Z
Lists: pgsql-hackers 
On Monday, May 5, 2025, Robert Haas <robertmhaas@gmail.com> wrote:

> On Thu, May 1, 2025 at 2:22 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > > The other approach would be to do what we do for the role options and
> just specify everything explicitly in the dump.  The GUC is only a default
> specifier so let's not leave room for defaults in the dump file.
> >
> > +1 for considering that option, although I am not sure which way is
> better.
>
> Actually, on further reflection, this doesn't work, right?
>

Doh.  I was thinking this was controlling admin/inherit/set defaults but
you are correct this controls whether additional commands are emitted
automatically instead of having to make it so manually.

David J.

Commits

  1. Add new GUC createrole_self_grant.

  2. Restrict the privileges of CREATEROLE users.

  3. Pass down current user ID to AddRoleMems and DelRoleMems.

  4. Refactor permissions-checking for role grants.

  5. Improve documentation of the CREATEROLE attibute.

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