On: A Critique of SQL, 40 Years Later

[tadfisher]

SELECT itself should be optional. Languages with expressions are fairly intuitive, e.g. "int x = foo.bar;" where "foo.bar" is equivalent to the "SELECT bar FROM foo;" SQL statement. I don't breathe SQL every day, so I'm struggling to come up with a case where removing SELECT results in parsing ambiguity.

[_solr → tadfisher]

> I'm struggling to come up with a case where removing SELECT results in parsing ambiguity

It's actually useful to the person reading the code. It clearly defines where a statement starts, what it does and makes reading a query close to reading English. Show a SELECT FROM WHERE query to someone who does not know SQL and the person will understand it. It might be a bit harder if you remove the SELECT.

[tremon → _solr]

It clearly defines where a statement starts

And this is another example of the ad-hoc problems of SQL: query terminators (;) are optional. If they weren't, there would be no abiguity where a statement would start: it's the first word after the previous terminator.

[mamcx → tadfisher]

> I'm struggling to come up with a case where removing SELECT results in parsing ambiguity.

Oh! Is super-ambiguous! Make the parser and enjoy it!

Lets make this more concrete:

     city SELECT id
     city ORDER id
     city id <-- Order or select???

You could then "favor" projection as the most important than the others. Ok, so:

     city city city

Which is the table, or the field?

[tadfisher → mamcx]

I didn't suggest removing ORDER or FROM. This still makes sense:

    id FROM city ORDER BY id

A plus is that sub-selects have more natural, expression-like syntax:

    id FROM (city WHERE elevation > 1000)

[jodrellblank → tadfisher]

How do you know if you are SELECTing or DELETEing?

[jolmg → tadfisher]

You mean the keyword; I meant the clause. "FROM foo" is optional to the syntax.