[jolmg]

Having SELECT come first makes sense to me because it's the only part of the statement that's required. FROM and everything else is optional.

Also when reading a statement, you're mostly interested in what the returned fields are rather details like where they came from or how they're ordered. It kind of makes sense to put it at the start.

Maybe other syntax forms have their benefits, specially when writing, but I don't think SQL's choice is completely senseless either.

[mamcx]

> SELECT come first makes sense to me because it's the only part of the statement that's required.

Only *IN SQL*.

You don't need it on the relational model, heck, no even in any other paradigm:

    1

That is!. (aka: SELECT 1)

So this:

    SELECT * FROM foo

is because SQL is made weird. More correctly, this should be only:

    foo

Also, SELECT is not required all the time, you wanna do:

    foo WHERE .id = 1
    foo ORDER BY .id
    foo ORDER BY .id WHERE .id = 1 //Note this is not valid in SQL, but because SQL is wrong!

But you probably think this as weird, because SQL in his peculiar implementation, that is, ok for one-off, ad-hoc query, and in THAT case, having the list of fields first is not that bad.

But now, when you see it this way, you note how MUCH nicer and simpler it could have been, because then each "fragment" of a SQL query could become *composable*.

But not on SQL, where the only "composition" is string concatenation, that is bad as you get.

[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.

[toto444]

> 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]

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]

> 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]

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]

How do you know if you are SELECTing or DELETEing?

[jolmg]

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

[cmrdporcupine]

Select doesn't mean that tho. Not in the relational model. It refers to the filtering clause.

Following their stupid English syntax, but using the proper verbs it should rightfully be "PROJECT x, y FROM foo SELECT WHERE a = b"