patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c

Phil Sorber <phil@omniti.com>

From: Phil Sorber <phil@omniti.com>
To: pgsql-hackers@postgresql.org
Date: 2011-07-27T19:21:42Z
Lists: pgsql-hackers

Attachments

Hello,

The attached patch changes the location of the dumpUserConfig call in
the dumpRoles function of pg_dumpall.

This is related to this thread:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php

Currently if you use 'ALTER ROLE rolename SET ROLE', pg_dumpall will
dump an 'ALTER ROLE' out right after the 'CREATE ROLE' statement.
Sometimes this will cause a conflict when a dependent role is not yet
created:

--
-- Roles
--

CREATE ROLE a;
ALTER ROLE a WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
NOREPLICATION;
ALTER ROLE a SET role TO 'b';
CREATE ROLE b;
ALTER ROLE b WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
NOREPLICATION;
CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
NOREPLICATION;

As you can see, role a is set to role b before role b is created.

This patch moves the call to dumpUserConfig to after the loop where
all the roles are created. This produces output like the this:

--
-- Roles
--

CREATE ROLE a;
ALTER ROLE a WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
NOREPLICATION;
CREATE ROLE b;
ALTER ROLE b WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN
NOREPLICATION;
CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
NOREPLICATION;
ALTER ROLE a SET role TO 'b';

Now this dump will succeed upon restore.

This passed all regression tests.

Thanks.