On Mon, 23 Feb 2026 at 13:35, jian he <jian.universality@gmail.com> wrote:
>
> On Sun, Feb 22, 2026 at 1:05 AM Andrew Dunstan <andrew@dunslane.net> wrote:
> >
> > What about options like these?:
> >
> > n/--schema
> > N/--exclude-schema
> > t/--table
> > T/--trigger
> > I/--index
> > P/--function
> > -filter
> >
> > We're not currently doing anything about those, but do they make sense when restoring a pg_dumpall archive?
We can keep these. If we use these options, then all databases will be
created(CREATE DATABASE) and based on n/N/t/T options, objects will be
restored.
Let say customers want to restore tables tb1, tb2, tb5 from the
cluster so only these tables will be restored even if they belong to
different-different databases.
> >
>
> We should reject these options too, since these options do not make
> sense for multiple databases, IMHO.
>
> >
> > pg_restore --clean --format=directory will produce DROP DATABASE will
> > process global objects,
> > it will also produce DROP DATABASE when processing each individual database.
> > To prevent errors during a subsequent restore, we can require
> > pg_restore --clean option must be used together with --if-exists when
> > restoring a non-plain-text dump.
> >
> > We could. Or we could just turn it on (and document that it will be turned on) in this case. I'd rather not force
peopleto use lots of flags.
> >
>
> Turning it on is OK for me.
>
> The attached patch addresses the two issues described above.
>
>
> --
> jian
> https://www.enterprisedb.com/
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
