Re: pg_dump --with-* options - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_dump --with-* options
Date
Msg-id CA+TgmoYW4ycbzZehdS9nOw60ZdtwzWZ-qoVpBe3+QCpeBxvKug@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump --with-* options  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Wed, Jun 18, 2025 at 1:21 PM Jeff Davis <pgsql@j-davis.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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: BackendKeyData is mandatory?