SELECT in ISO/IEC-standard SQL prescribes the following syntactical order for the sub-clauses:

SELECT     projection-expressions FROM     sources WHERE     predicate-expression GROUP BY     key-expression HAVING     predicate-expression ORDER BY     ordering-expressions 

While the actual execution order is this:

FROM     sources WHERE     predicate-expression GROUP BY     value-expression HAVING     value-expression SELECT     projection-expressions ORDER BY     ordering-expressions 

To novice users of SQL it becomes surprising that a projection defined in the SELECT clause is not available in the WHERE or GROUP BY clauses even though it’s declared first – given that computer programs generally follow the top-down execution order.

It’s also surprising that SQL authors are required to repeat their expressions in SELECT, WHERE, and GROUP BY clauses redundantly or use a subquery which does not lend itself to a succinct query. At least when the user is familiar with the actual clause execution order they know why they need to repeat themselves, but that doesn’t stop it being frustrating.

This problem, and other related issues, is documented in this article I found: https://blog.jooq.org/2016/12/09/a-beginners-guide-to-the-true-order-of-sql-operations/ and it’s no surprise that a QA on StackOverflow has almost 30,000 views: https://stackoverflow.com/questions/3241352/using-an-alias-column-in-the-where-clause-in-postgresql

It made me wonder if any implementations of SQL allow for this more “logical” ordering of clauses. I note that Linq in .NET does actually follow this order, though I wouldn’t describe it as being a true SQL implementation, but indeed, in Linq the equivalent would be:

source // FROM equivalent     .Where( predicate-expression )     .GroupBy( key-expression )     .Where( predicate-expression ) // HAVING equivalent     .Select( projection-expression )     .OrderBy( ordering-expression ) 

(I also like how Linq lets you add a Select() projection anywhere in the command sequence so you can use your evaluated expressions without needing to invoke expressions again).

So, do any SQL implementation let you express queries in a more logical structure?