Re: fixing CREATEROLE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fixing CREATEROLE
Date
Msg-id 1397112.1746044953@sss.pgh.pa.us
Whole thread Raw
In response to Re: fixing CREATEROLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fixing CREATEROLE
Re: fixing CREATEROLE
List pgsql-hackers
necro-ing an old thread ...

Robert Haas <robertmhaas@gmail.com> writes:
> [ v4-0002-Add-new-GUC-createrole_self_grant.patch ]

I confess to not having paid close enough attention when
these patches went in, or I would have complained about
createrole_self_grant.  It changes the user-visible behavior
of SQL commands, specifically CREATE ROLE.  We have learned
over and over again that GUCs that do that are generally
a bad idea.

Two years later, it's perhaps too late to take it out again.
However, I'd at least like to complain about the fact that
it breaks pg_dumpall, which is surely not expecting anything
but the default behavior.  If for any reason the restore is
run under a non-default setting of createrole_self_grant,
there's a potential of creating role grants that were not
there in the source database.  Admittedly the damage is
probably limited by the fact that it only applies if the
restoring user has CREATEROLE but not SUPERUSER, which
I imagine is a rare case.  But don't we need to add
createrole_self_grant to the set of GUCs that pg_dump[all]
resets in the emitted SQL?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Add function to get memory context stats for processes
Next
From: Daniel Gustafsson
Date:
Subject: Re: pgsql: Add function to get memory context stats for processes