Scott Dunbar <sc...@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
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
