On 2026-02-23 Mo 3:58 AM, Mahendra Singh Thalor wrote:
> 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.
OK, I left that alone. We can revisit later if it bothers anyone.
>
>> 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.
>>
>>
OK, here is my commit candidate patch.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
