Re: dumping database privileges broken in 9.6 - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: dumping database privileges broken in 9.6
Date
Msg-id 20160629155016.GP21416@tamriel.snowman.net
Whole thread Raw
In response to dumping database privileges broken in 9.6  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: dumping database privileges broken in 9.6  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> Do this:
>
> CREATE DATABASE test1;
> REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
>
> Run pg_dumpall.
>
> In 9.5, this produces
>
> CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> REVOKE ALL ON DATABASE test1 FROM PUBLIC;
> REVOKE ALL ON DATABASE test1 FROM peter;
> GRANT ALL ON DATABASE test1 TO peter;
> GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
>
> In 9.6, this produces only
>
> CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> GRANT TEMPORARY ON DATABASE test1 TO PUBLIC;
> GRANT ALL ON DATABASE test1 TO peter;
>
> Note that the REVOKE statements are missing.  This does not
> correctly recreate the original state.

I see what happened here, the query in dumpCreateDB() needs to be
adjusted to pull the default information to then pass to
buildACLComments(), similar to how the objects handled by pg_dump work.
The oversight was in thinking that databases didn't have any default
rights granted, which clearly isn't correct.

I'll take care of that in the next day or so and add an appropriate
regression test.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: bug in citext's upgrade script for parallel aggregates
Next
From: Robert Haas
Date:
Subject: Re: fixing consider_parallel for upper planner rels