| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: should pg_dumpall --clean apply to database in --exclude-database |
| Date: | 2026-10-06 06:04:38 |
| Message-ID: | CAKFQuwb4C5qwALhEkEARiL4dcfuqn2DW0DL5v9wpt44HG8T_0Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Monday, October 5, 2026, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> Hi.
>
> https://www.postgresql.org/docs/devel/app-pg-dumpall.html
> --clean options says
> """
> Emit SQL commands to DROP all the dumped databases, roles, and
> tablespaces before recreating them.
> """
>
> Currently, with --clean, pg_dumpall still emits a DROP DATABASE
> command for databases excluded with --exclude-database.
> It is not clear to me whether --clean is meant to apply to excluded
> databases.
>
> Let's see how --clean and --exclude-table work.
> If I say
> --clean --exclude-table=onek2
> then no SQL command ``DROP TABLE public.onek2``.
>
As documented, and per POLA, no. The database is neither dumped nor going
to be recreated. It indeed should behave as your example with the excluded
table does. The dump file should be unaware of the existence of said
database. Dropping it while not recreating it is quite a bad outcome.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shubhra Jain | 2026-10-06 06:07:41 | Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0 |
| Previous Message | Richard Guo | 2026-10-06 05:56:21 | Re: subquery pullup misses lateral refs in join alias Vars |