On Fri, Oct 6, 2017 at 12:29 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > > 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. > > To me it seems that a refactoring which requires pg_dump to behave > differently in small ways like this based on whether it is being > called by pg_dumpall or not is probably not a good refactoring. And I > don't see why the proposal from Tom that started this thread would > require such a thing to be true. > Before refactoring, pg_dumpall doesn't print "create database" commands for both tempalte1 and postgres database, but on the other hand pg_dump dump the create database commands with --create option. To keep the behavior of all the database attributes in the dump of both pg_dump and pg_dumpall, the code is unified and moved into pg_dump. But to retain the pg_dumpall behavior of not dumping the "create database" commands, a new option is added to pg_dump to skip dumping the create database commands. The new option name is now "--skip-create-default-db", this can be used normal user also when try to dump the postgres database to not let create the database commands in the dump. >From your list, I would say that (1) and (3) seem like behaviors that > we either want or do not want. Whether pg_dump or pg_dumpall is > involved seems irrelevant. (2) seems like it might need some special > handling, but that could be handled in pg_dumpall by just not calling > pg_dump at all for those database. I didn't any better way other than creating a new option to not let the default db create database commands to dump, so I renamed the older option to better one and change the behavior to use by the normal users also. Updated patch attached. Regards, Hari Babu Fujitsu Australia
pg_dump-and-pg_dumpall-database-handling-refactoring_v8.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
