MIME-Version: 1.0
References: <3f22a8bb-29e8-40cc-97a1-309181da2c13@dunslane.net>
 <CAKYtNApm8nA6hVMNkSjeNPiwTZBWYkhJKU7haQghUZdw74tYxA@mail.gmail.com>
 <CACJufxHc5Rp2roGyJOVnCk=Mx8_42_9vCGJSCFpLB5=AFQqHTQ@mail.gmail.com>
 <CAKYtNAoz-Sz2X1ipkQ5x1Sh08AMyy1kDRGfeRW3P1W-QoN+WOg@mail.gmail.com>
 <CAC6VRoZU2L2GX7+bXpsZ6bo+NuxBOe1dTGDPzKobUL4KVdm46A@mail.gmail.com>
 <CAKYtNApq+6Riz26So1nmXkRpL_7o868+r6i=wxQ+AgGQ4oSLig@mail.gmail.com>
 <CAC6VRoZbP=-=a+a78RoWcs2L4=4VEDZqJMg+7SyUAcSHATyDAQ@mail.gmail.com>
 <CAC6VRoY-1WC_O5UDwKzNc18LXLwjuTFb+qMNY3gaF3cCov6M6g@mail.gmail.com>
 <CAKYtNArc3j8Akb+nB1QyJLKic7ej7vKZqKnv_mbB+iQAJRzLnA@mail.gmail.com>
 <CAC6VRoat6NPcS6vfGrPrwaQB3G1JHLSqDeAkf1AJ7npWrwhnUQ@mail.gmail.com>
 <CAKYtNAp=TFEZWQbTRZso3kNaD9BH=-JPNQ30mT60cJN_04hEog@mail.gmail.com>
 <4022765f-38ee-48a3-b246-615b3f8e1c23@dunslane.net> <CAKYtNAq73_UeL4-0wgu9rawctHdS2zhpzWtqVuOChCS3M+2Ymg@mail.gmail.com>
 <CACJufxFs9NXXTeb78i2MD+pnZootayAtiGcNHNeU35SmQgMjbA@mail.gmail.com>
 <59d3616f-6d6d-40d5-87e2-e019e350b52d@dunslane.net> <CACJufxEnmJ8otfmN7Kp110Wqi=M4YE0-zn-W6SK+eTpWuZw_fg@mail.gmail.com>
In-Reply-To: <CACJufxEnmJ8otfmN7Kp110Wqi=M4YE0-zn-W6SK+eTpWuZw_fg@mail.gmail.com>
From: Mahendra Singh Thalor <mahi6run@gmail.com>
Date: Mon, 23 Feb 2026 14:28:43 +0530
Message-ID: <CAKYtNAqxjQMLVPfz6XESqszhxZKgigi7UEBzBhz_Wj_Bnasdag@mail.gmail.com>
Subject: Re: Non-text mode for pg_dumpall
To: jian he <jian.universality@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, tushar <tushar.ahuja@enterprisedb.com>, 
	Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAKYtNAqxjQMLVPfz6XESqszhxZKgigi7UEBzBhz_Wj_Bnasdag%40mail.gmail.com>
Precedence: bulk

On Mon, 23 Feb 2026 at 13:35, jian he <jian.universality@gmail.com> wrote:
>
> On Sun, Feb 22, 2026 at 1:05=E2=80=AFAM Andrew Dunstan <andrew@dunslane.n=
et> 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=3Ddirectory will produce DROP DATABASE will
> > process global objects,
> > it will also produce DROP DATABASE when processing each individual data=
base.
> > 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 tur=
ned 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/


--=20
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com