Re: pg_dump --with-* options
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-06-12T20:39:00Z
Lists: pgsql-hackers
On Thu, Jun 12, 2025 at 4:22 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > On Thu, Jun 12, 2025 at 04:12:35PM -0400, Corey Huinker wrote: > > The use case for --statistics-only is to extract the existing statistics > > for the tables and indexes that are involved in a given query that is > > giving you problems, allowing you to apply those statistics to an > existing > > QA/dev database and tweak them without further impacting operations on > the > > production database. I think this will prove to be very useful, and > having > > a --statistics-only flag conveys the clear intent of "I want the stats, > and > > only the stats", > > I do think this is useful functionality, I only suggested removing it > because AFAICT it is redundant, i.e., you can accomplish the same thing > with --with-statistics --no-schema --no-data. It seems like we're trying > to avoid having multiple ways to do the same thing. > By that same argument, we should remove --schema-only and --data-only as well. I think we shouldn't because those two options have proved very convenient for users and they convey clear intent to the person reading the script, and I believe that --statistics-only will prove the same over time. > > If we're hot to remove options, how about we remove the sections flags? > > Their utility is reliant upon the user understanding exactly which things > > go in which section, and further assumes that everything > deterministically > > goes in exactly one section, which is no longer the case as Jeff > > pointed out recently. They have outlived their usefulness. > > I almost brought this up earlier as something else we could potentially > trim. That's v19 material at this point, though. > +1 for 19.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Simplify options in pg_dump and pg_restore.
- 6a46089e458f 19 (unreleased) landed
- a3e8dc143862 18.0 landed
-
pg_dump: reject combination of "only" and "with"
- 0ed92cf50cc4 19 (unreleased) landed
- 60121890f7f2 18.0 landed
-
Change pg_dump default for statistics export.
- 34eb2a80d5a3 18.0 cited