Thread: Prevent accidental whole-table DELETEs and UPDATEs

Prevent accidental whole-table DELETEs and UPDATEs

From
Nikolay Samokhvalov
Date:
In many cases, a DELETE or UPDATE not having a WHERE clause (or having it with a condition matching all rows in the table) is a sign of some kind of mistake, leading to accidental data loss, performance issues, producing a lot of dead tuples, and so on. Recently, this topic was again discussed [1]

Attached is a patch implemented by Andrey Boroding (attached) during our today's online session [2], containing a rough prototype for two new GUCs:

- prevent_unqualified_deletes
- prevent_unqualified_updates

Both are "false" by default; for superusers, they are not applied.

There is also another implementation of this idea, in the form of an extension [3], but I think having this in the core would be beneficial to many users.

Looking forward to your feedback.

Attachment

Re: Prevent accidental whole-table DELETEs and UPDATEs

From
Tom Lane
Date:
Nikolay Samokhvalov <samokhvalov@gmail.com> writes:
> In many cases, a DELETE or UPDATE not having a WHERE clause (or having it
> with a condition matching all rows in the table) is a sign of some kind of
> mistake, leading to accidental data loss, performance issues, producing a
> lot of dead tuples, and so on. Recently, this topic was again discussed [1]

> Attached is a patch implemented by Andrey Boroding (attached) during our
> today's online session [2], containing a rough prototype for two new GUCs:

> - prevent_unqualified_deletes
> - prevent_unqualified_updates

This sort of thing has been proposed before and rejected before.
I do not think anything has changed.  In any case, I seriously
doubt that something that's basically a one-line test (excluding
overhead such as GUC definitions) is going to meaningfully
improve users' lives.  The cases that I actually see reported
are not "I left off the WHERE" but more like "I fat-fingered
a variable in a sub-select so that it's an outer reference,
causing the test to degenerate to WHERE x = x", or perhaps
"I misunderstood the behavior of NOT IN with nulls, ending up
with a constant-false or constant-true condition".  I'm not sure
if there's a reliable way to spot those sorts of not-so-trivial
semantic errors ... but if we could, that'd be worth discussing.

            regards, tom lane