On Sat, Sep 30, 2017 at 3:31 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Sep 29, 2017 at 12:44 AM, Vaishnavi Prabakaran > <vaishnaviprabaka...@gmail.com> wrote: > > Option name "--enable-pgdumpall-behaviour" is very generic > > Yeah, that's a terrible name, at least in my opinion. > OK. I will use a new name based on the discussion. > and it is better > > to rename it to something that reflects its functionality like > > --skip-default-db-create/--no-default-db-create > > But I wonder why this patch needs a new option at all? > There are some differences in handling database objects between pg_dump and pg_dumpall, To retain both pg_dump and pg_dumpall behavior even after refactoring, this option is added. Currently this option is used mainly for the three purposes. 1. Don't print unnecessary CREATE DATABASE options like ENCODING, LC_COLLATE and LC_CTYPE options if the default encoding is same with the above values. The above behavior is as per the pg_dumpall, but it can be changed to print irrespective of the default encoding. 2. Do not dump postgres and template0 databases. 3. Set default_transaction_read_only = off. As per the following comment in pg_dumpall, based on that flag the GUC is set, to retain the same behavior even after this refactoring. /* * Restore will need to write to the target cluster. This connection * setting is emitted for pg_dumpall rather than in the code also used * by pg_dump, so that a cluster with databases or users which have * this flag turned on can still be replicated through pg_dumpall * without editing the file or stream. With pg_dump there are many * other ways to allow the file to be used, and leaving it out allows * users to protect databases from being accidental restore targets. */ fprintf(OPF, "SET default_transaction_read_only = off;\n\n"); we can remove the usage -1 and retain the usage-2 with modified option name as --no-default-database or similar. Any opinions about the usage-3, In case if we need to retain that change, any best solution to the option name? Regards, Hari Babu Fujitsu Australia