Re: Non-text mode for pg_dumpall

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Non-text mode for pg_dumpall
Date: 2026-02-23 08:04:55
Message-ID: CACJufxEnmJ8otfmN7Kp110Wqi=M4YE0-zn-W6SK+eTpWuZw_fg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 22, 2026 at 1:05 AM Andrew Dunstan <andrew(at)dunslane(dot)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 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/

Attachment Content-Type Size
v18-0001-misc-fix-for-v18.no-cfbot application/octet-stream 5.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-02-23 08:14:45 Re: Flush some statistics within running transactions
Previous Message Peter Eisentraut 2026-02-23 07:32:34 Re: enable fallthrough warnings on clang