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.
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 |