Scott Dunbar <scott@xigole.com> wrote:
> I guess this makes sense but it does seem strange that I can enter
> garbage in a query but it still runs.
It wasn't garbage.
> And in my case the output from this (the entire table) was then
> used in a delete statement that toasted the entire table.
I can suggest a few ways to protect yourself in such situations.
(1) I generally run any DELETE statement against data I care about
as a SELECT first. It's generally pretty easy to write it as a
SELECT tbl.* FROM which can be converted to DELETE FROM tbl after
reviewing what matches.
(2) When in doubt, use BEGIN; before running the statement. You
can review the count, run SELECTs to look at the results, etc.,
before running COMMIT; to make it "stick".
(3) Less convenient, but sometimes useful, is to EXPLAIN your query
before actually running it. If you do that with your delete, you'll
see the criterion applied to a table other than what you were
expecting, which might alert you to the problem. The estimated row
count at the top level of the plan might be another red flag.
> Allowing bogus SQL just seems "wrong" but I do understand what's
> going on.
If you did you wouldn't call a well formed, unambiguous, standard-
conforming statement bogus. It did exactly what you said; just not
what you meant. It pays to be a bit paranoid when running ad hoc
DML in case you accidentally don't say what you mean.
-Kevin