Re: Refactor handling of database attributes between pg_dump and pg_dumpall

On 03/21/2017 08:02 AM, Haribabu Kommi wrote:
> Solution -1) Just ignore dumping these CREATE DATABASE
> commands and provide the user information in the documentation
> to create "postgres" and "template1" database in the target in case
> if they don't exist. If this kind of cases are very rare.
>
> Solution-2) Add a new command line option/some other settings
> to indicate the pg_dump execution is from pg_dumpall and follow
> the current refactored behavior, otherwise follow the earlier pg_dump
> behavior in handling CREATE DATABASE commands for "postgres"
> and "template1" databases.

I am leaning towards (2) since I feel having pg_dump act differently 
depending on the name of the database is a quite surprising behavior. It 
makes more sense to let a tool like pg_dumpall handle logic like that.

> 2.  In dumpDatabases function before calling the runPgDump command,
> Before refactoring, it used to connect to the database and dump
> "SET default_transaction_read_only = off;" to prevent some accidental
> overwrite of the target.
>
> I fixed it in the attached patch by removing the connection and dumping
> the set command.
>
> Does it needs the similar approach of solution-2) in previous problem and
> handle dumping the "SET default_transaction_read_only = off;" whenever
> the CREATE DATABASE and \connect command is issued?

Hm, that is a bit annoying. I do not think we want to change any 
behavior here, either of pg_dump or pg_dumpall, but I also do not like 
having to add two new flags to pg_dump (one for including the ALTER 
DATABASE commands but not CREATE DATABASE, and another flag for 
default_transaction_read_only) or a special flag similar to 
--binary-upgrade.

None of these options seem optimal to me, and I do not have any strong 
preference other than that we should avoid breaking pg_dump or changing 
behavior not related to the database attributes.

Andreas