Re: pg_dump --with-* options

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-08-01 20:35:15
Message-ID: CADkLM=eB5kf13X6zr5H=RCCE8d5cTiXeu1pBCF1t=e4G4v4qOQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 1, 2025 at 4:02 PM Jeff Davis <pgsql(at)j-davis(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Borisov 2025-08-01 20:51:04 Re: Improve the performance of Unicode Normalization Forms.
Previous Message Arseniy Mukhin 2025-08-01 20:22:13 Re: amcheck support for BRIN indexes