"Euler Taveira" <euler@eulerto.com> writes:
> On Tue, May 5, 2026, at 7:51 AM, Álvaro Rodríguez wrote:
>> We have hit an issue with pg_dumpall --roles-only where the role grants
>> to other roles can't be reapplied in a clean database, if the bootstrap
>> superuser does not have the same name in both databases.
> This is not a bug. There is no way that pg_dumpall knows that the bootstrap
> user you want is another one.
I don't think that pg_dumpall is to be blamed; this is the backend's
fault. I thought we had made this better in dd1398f13, but it still
seems rather bogus:
regression=# create user super with superuser;
CREATE ROLE
regression=# create user a;
CREATE ROLE
regression=# create user b;
CREATE ROLE
regression=# grant a to b granted by super;
ERROR: permission denied to grant privileges as role "super"
DETAIL: The grantor must have the ADMIN option on role "a".
Surely a superuser should be considered to have admin options
on everything. Even more bogus, compare these results:
regression=# \c - super
You are now connected to database "regression" as user "super".
regression=# grant a to b granted by super;
ERROR: permission denied to grant privileges as role "super"
DETAIL: The grantor must have the ADMIN option on role "a".
regression=# grant a to b;
GRANT ROLE
Anyone would think that "GRANTED BY current_user" has the
same effect as omitting the clause, but here it doesn't.
So it seems to me that we're missing a superuserness check
somewhere in this, but I'm not entirely sure which bit of
code to blame.
I agree that the answer for existing branches is probably
going to be "so don't do that", but maybe we can improve
this in v19 or later.
regards, tom lane
