From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Vaishnavi Prabakaran <vaishnaviprabakaran(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactor handling of database attributes between pg_dump and pg_dumpall |
Date: | 2017-10-05 13:29:27 |
Message-ID: | CA+TgmoZ_Jq11Az=UVfN94jR7_zuLO0Pyp7voMNN=XdvEwG8-MQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-05 13:44:26 | Re: postgres_fdw super user checks |
Previous Message | Erik Rijkers | 2017-10-05 13:28:07 | v10 bottom-listed |