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. >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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers