Re: Non-text mode for pg_dumpall - Mailing list pgsql-hackers

From jian he
Subject Re: Non-text mode for pg_dumpall
Date
Msg-id CACJufxEnmJ8otfmN7Kp110Wqi=M4YE0-zn-W6SK+eTpWuZw_fg@mail.gmail.com
Whole thread
In response to Re: Non-text mode for pg_dumpall  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Non-text mode for pg_dumpall
List pgsql-hackers
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 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/

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: enable fallthrough warnings on clang
Next
From: Bertrand Drouvot
Date:
Subject: Re: Flush some statistics within running transactions