From: Tom Lane <tgl@sss.pgh.pa.us>
To: vignesh C <vignesh21@gmail.com>
cc: Joan <aseques@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: pg_dump needs an option to add the force flag to the drop
 database
In-reply-to: 
 <CALDaNm0PLojTF0B_eyDxV_HTZSejU7tKSCgsbtR2cf6rsHsUGA@mail.gmail.com>
References: 
 <CAP4s+CGPvvN4RioLr1kFXXTEQ3GRkO8gx2vuF7Sihus=K7ipEA@mail.gmail.com>
 <CALDaNm0PLojTF0B_eyDxV_HTZSejU7tKSCgsbtR2cf6rsHsUGA@mail.gmail.com>
Comments: In-reply-to vignesh C <vignesh21@gmail.com>
	message dated "Tue, 18 Jul 2023 09:10:45 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4134280.1689652276.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Jul 2023 23:51:16 -0400
Message-ID: <4134281.1689652276@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4134281.1689652276%40sss.pgh.pa.us>
Precedence: bulk

vignesh C <vignesh21@gmail.com> writes:
> On Mon, 17 Jul 2023 at 14:18, Joan <aseques@gmail.com> wrote:
>> Having an option to add the FORCE option to either the generated dump b=
y pg_dump, or in the pg_restore would be very useful when restoring the da=
tabases so it would avoid having to do scripting.

> It would be better to raise this enhancement request in -hackers, as
> it can be discussed there and taken forward accordingly from there.

Yeah, this is not a bug.

I'm not sure that it's a sane feature request either.  pg_dump scripts are
not designed to deal with concurrent modifications to the target database
during restore, and I doubt that we want to invest effort in making them
proof against such situations.  Even if you only consider read-only
concurrent accesses, what client is going to be pleased with seeing a
half-restored database?  So I don't quite follow what is the use-case
for doing DROP DATABASE FORCE here.  Realistically you need a stronger
defense against concurrent users than that would offer.

			regards, tom lane