4 ms·
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
by tadfisher 4y ago
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.
- jolmg 4y agoYou mean the keyword; I meant the clause. "FROM foo" is optional to the syntax.
- toto444 4y ago> 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 4y agoIt 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 4y ago> 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 4y agoI 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 4y agoHow do you know if you are SELECTing or DELETEing?