Hacker News Reader

Comment by jerf | Hacker News Reader

This isn't quite up there with the "billion dollar" NULL mistake, but in hindsight it would have saved a lot of people a lot of trouble if the SQL grammar for UPDATE and DELETE required a WHERE clause.

View on HN

Yup. Even if it's just to add a WHERE 1 = 1, at least then you've deliberately loaded and then set off your footgun.

In fact I would go one step further and say why does 'where' default to ALL? You did not say what you wanted. So you should get nothing. This should be true for select and delete as well as well as update.

If I just do 'SELECT *' and execute it, it does not rotate through all the tables. I did not specify it. Same with 'SELECT from xyz' if I can not have it empty and return all. Yet where is special somehow.

Because tables and SQL operators are really sets and acting on sets, so naturally operations take place on the set unless a subset is specified. Once you completely and totally internalize this SQL is pretty intuitive, although I think that the clause order might be nicer in a different order.

For example, I would like SELECT to be FROM, WHERE, SELECT. UPDATE could be UPDATE, WHERE, SET. But then DELETE would end up inconsistent...

> If I just do 'SELECT *' and execute it, it does not rotate through all the tables.

Because you did not specify what set you wanted to operate in, and the set of sets isn't meaningful because of schematic differences.

> Same with 'SELECT from xyz' if I can not have it empty and return all.

SELECT is asking what pieces of the subsets (rows) you want to display. If you don't ask for any, you don't get any. You are asking for the number of rows in xyz times zero. That's zero. You can write SELECT 1 FROM xyz and get 1 returned for each subset.

Oh I get that, and that kind of was my point. I created those to show the inconsistency of the interface that SQL is. You have to internalize those inconsistent bits. Sometimes you specify, other times you get everything out of the different sets. The mental model of SQL is split. In some cases it is 'get these items from the set and if you dont you will get a syntax error' in other cases it is 'filter these items from the whole set and if you dont you get everything'. I see a lot of people new to SQL who that trips up. Some people are sayin 'well just for update/delete make the where condition not optional'. That at least seems fair and fixes the easy issue, but then that is one more inconsistency in the language that SQL is. I am saying just go one step further and make unconditional always. There are some who disagree. That is fine. My guess we get a mode in most SQLs with the update/delete one. I think that is at least a decent compromise.

Honestly, I think the problem is just that SQL isn't a particularly great language. This is an example of where the syntax and semantics are coupled so tightly that it's just gonna be confusing no matter what you do. My vote would be to not even bother with a "literate" kind of language.

My problem with that suggestion is that it becomes automatic, if I just know I need to short circuit every query to get results I think I'd fall into a bad habit. If update and delete require special thought, you need to take that thought specifically when you're doing those actions. We're adding friction for those dangerous commands, not every command.

A fun Postgres extension to require this: https://github.com/eradman/pg-safeupdate

What's fun about it? I cant imagine why this is not the first recommendation when you setting up a new postgres DB.

And yeah, thank you. Today i learned new thing.

I would really love if they accepted this as a non-backwards compatible change.

Or at least (for now) a configurable option in the database config, so each site can switch it on as they like.

Adding "UPDATE xxx WHERE yyy SET z=42" to the grammar would be a nice addition too.

datagrip won't run such a query by default

Reply on news.ycombinator.com