Re: "Re: Question about grant create on database and pg_dump/pg_dumpall - Mailing list pgsql-hackers

From Robert Haas
Subject Re: "Re: Question about grant create on database and pg_dump/pg_dumpall
Date
Msg-id CA+TgmoYGbeiDRvivJHsC5e7-BMxnmE7vNg571i8OWOx6HK=OOQ@mail.gmail.com
Whole thread Raw
In response to Re: "Re: Question about grant create on database and pg_dump/pg_dumpall  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Sep 29, 2016 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The fundamental thing we have to do in order to move forward on this is
> to rethink what's the division of labor between pg_dump and pg_dumpall.
> I find the patch as presented quite unacceptable because it's made no
> effort to do that (or even to touch the documentation).
>
> What do people think of this sketch:
>
> 1. pg_dump without --create continues to do what it does today, ie it just
> dumps objects within the database, assuming that database-level properties
> will already be set correctly for the target database.
>
> 2. pg_dump with --create creates the target database and also sets all
> database-level properties (ownership, ACLs, ALTER DATABASE SET, etc etc).
>
> 3. pg_dumpall loses all code relating to individual-database creation
> and property setting and instead relies on pg_dump --create to do that.
> This would leave only the code relating to "pg_dumpall -g" (ie, dump roles
> and tablespaces) within pg_dumpall itself.

Seems like a good sketch.

> One thing that would still be messy is that presumably "pg_dumpall -g"
> would issue ALTER ROLE SET commands, but it's unclear what to do with
> ALTER ROLE IN DATABASE SET commands.  Should those become part of
> "pg_dump --create"'s charter?  It seems like not, but I'm not certain.

I could go either way on this.

> Another thing that requires some thought is that pg_dumpall is currently
> willing to dump ACLs and other properties for template1/template0, though
> it does not invoke pg_dump on them.  If we wanted to preserve that
> behavior while still moving the code that does those things to pg_dump,
> pg_dump would have to grow an option that would let it do that.  But
> I'm not sure how much of that behavior is actually sensible.

I'm not sure, either, but it's usually bad when dump-and-restore
doesn't dump-and-restore things which a user might reasonably have
changed.  That tends to lead to bug reports and/or pg_upgrade
failures.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL]Understanding “max_wal_size” and “min_wal_size” parameters default values from postgresql.conf file
Next
From: Robert Haas
Date:
Subject: Re: Showing parallel status in \df+