Re: Regarding feature #6367 "DROP DATABASE can now take the option FORCE ..."

I would also like to suggest to prompt for a password when drop db is chosen. Especially force drop being critical one. This would prevent accidental drops. 

Vaij

On Tue, Jun 13, 2023 at 6:53 AM Dave Page <dpage@pgadmin.org> wrote:

On Tue, 13 Jun 2023 at 11:29, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Tue, Jun 13, 2023 at 3:49 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, 13 Jun 2023 at 11:13, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Tue, Jun 13, 2023 at 2:50 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, 13 Jun 2023 at 09:36, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Hackers

I have started the implementation for feature #6367 "DROP DATABASE can now take the option FORCE to drop a database even if other users are connected".

For that, I figure out two places one in the Properties tab of the Databases collection node and the other in the context menu on the individual database node except the maintenance database. This feature will be available from PG 13 and above. Please refer to the screenshot below:

   The 'Drop with Force' button is visible only on the Databases collection node. For other collection nodes, it is a 'Drop Cascade'.

Right, because CASCADE means drop dependent objects as well, but FORCE means disconnect connected users first.

 

 

Please review and let me know your thoughts. Is there any place where I can use this? 

I'm not sure what you mean with your last question,

    I mean apart from the Properties tab and Context menu, do I need to implement DROP DATABASE...WITH (FORCE)?

 

but I think the wording needs some thought. Currently we have:

Delete/Drop

Drop Cascade

Delete/Drop with Force

I would suggest:

Delete

Delete (Cascade)

Delete (Force)

And we should probably re-order the menu to place those options together (and make sure the confirmation dialogues have appropriately matching text).

    I am not sure why we have used Delete/Drop, but for me, DROP seems appropriate as in the backend we used DROP Queries, so can we have 
    Drop

    Drop (Cascade)

    Drop (Force)

Because in the past people (I don't recall who) claimed that "Drop" was not intuitive. I recall arguing that it's the standard SQL terminology, but iirc we eventually settled on Delete/Drop, which is, frankly, messy.

    So which option (Delete or Drop) should we use?

I think Delete, as it's more natural and expected in a GUI which is largely trying to prevent the user from needing to think about SQL. 

--

Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com