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

From Corey Huinker
Subject Re: pg_dump --with-* options
Date
Msg-id CADkLM=eB5kf13X6zr5H=RCCE8d5cTiXeu1pBCF1t=e4G4v4qOQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump --with-* options  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Fri, Aug 1, 2025 at 4:02 PM Jeff Davis <pgsql@j-davis.com> wrote:
On Thu, 2025-07-31 at 16:28 -0400, Corey Huinker wrote:
>
> In general, I like the idea of --include, but it would need to be
> consistent in behavior across pg_dump/pg_restore/pg_upgrade(if
> applicable).

How should you exclude stats when doing pg_restore? Presumably, --
include=data,schema. But it's a bit strange if "--include" is the only
way to exclude something.

Yes, that's how you'd do it, if we go with the request for one --include option (or series of options) and no --exclude option (or series of options). I was under the impression that was the stated feature of --include.
 
There are enough nuances and details here that I think the next step is
for someone to turn the idea for --include into a reviewable patch, so
that we can compare it to what we have now and see if people generally
think it's an improvement over what we have now.

If the defaults aren't changing, then --include is a big step backwards, requiring --include=data,schema,statistics to actually get statistics in a dump. I think that's cumbersome and weird.

pgsql-hackers by date:

Previous
From: Arseniy Mukhin
Date:
Subject: Re: amcheck support for BRIN indexes
Next
From: Alexander Borisov
Date:
Subject: Re: Improve the performance of Unicode Normalization Forms.