From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump --with-* options |
Date: | 2025-06-23 17:38:10 |
Message-ID: | CA+TgmoYW4ycbzZehdS9nOw60ZdtwzWZ-qoVpBe3+QCpeBxvKug@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 18, 2025 at 1:21 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> The only downside of this approach is that we'd be stuck with both --
> with-statistics and --no-statistics forever. That's a bit inconsistent
> with the other options, and it doesn't satisfy Robert's concern about
> the --help output. But Robert also wants stats off by default for
> pg_dump and on by default for pg_restore, which I think means we need
> both --with-statistics and --no-statistics anyway. Robert, comments?
Sorry, I've been largely away from email for the last week due to work
commitments.
I had thought we had a consensus that pg_upgrade should preserve stats
but regularly pg_dump shouldn't include them; perhaps I misunderstood
or that changed.
What confuses me about what you've written here specifically is that
pg_dump and pg_restore are different programs with different option
sets. So when you say we need both --with-statistics and
--no-statistics, I guess that's true, but we're not talking about the
same executable in both cases. It seems to me that pg_restore should
restore everything that was dumped, but that there should be (as there
are) various --no-whatever switches to skip unwanted items. But
pg_dump should have dump a reasonable set of things by default, and
the user should be able to add to that or subtract from it.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2025-06-23 18:42:44 | Re: BackendKeyData is mandatory? |
Previous Message | vignesh C | 2025-06-23 17:03:50 | Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly |