On Mon, 23 Feb 2026 at 13:35, jian he <[email protected]> wrote: > > On Sun, Feb 22, 2026 at 1:05 AM Andrew Dunstan <[email protected]> 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 people to 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
