That's quite funny... but ultimately futile. It doesn't say what happens if you say "DROP TABLE xyz<ENTER>WHERE...ohshit". (The <ENTER> bit is because you're used to doing that in your preferred SQL-DB editor.)
One should NEVER do anything non-scripted on a production system. ALWAYS enter it into a file and then do the "run-sql-from-a-file" command.
EDIT: Yes, I also realize that "rm -rf /" can theoretically happen if you have a bad variable substitution, but you MUST turn on the flags that cause your shell to error out instead of just substituting the empty string.
Protecting against every damned footgun is not possible. But some footguns blow users' feet off so often (this one because shell scripting is so tricky and dangerous) that it's est to do something about it.
Indeed not, but just having the extra step of "write this into a file" (and perhaps have someone look it over) catches most of those really bad mistakes.
It's really about NOT getting into the habit of "just fix it in production". That way lies madness.
One should NEVER do anything non-scripted on a production system. ALWAYS enter it into a file and then do the "run-sql-from-a-file" command.
EDIT: Yes, I also realize that "rm -rf /" can theoretically happen if you have a bad variable substitution, but you MUST turn on the flags that cause your shell to error out instead of just substituting the empty string.