I meant for each in the cursor context. Given the boilerplate required to write a proper cursor (don't forget to deallocate!), there's no reason it can't use a simpler syntax for most situations. Granted, if you're using a cursor, you might have bigger issues, but that's beside the point.

CTEs may be inline views but in my experience that seems like a ret-conned explanation. At least in my experience I've only ever used them for recursion (and in pivots). They try to force set theory onto a process that lends itself much, much better to languages that naturally support recursion through the use of reusable functions.

Having to create permanent functions in your database to do temporary things is nonsense. There is no good reason I can't define a piece of reusable SQL that exists only for the life of the stored procedure or query and isn't suitable to be made permanent. If the function can be made permanent, it can be made temporary. This is the kind of 70s-era language constructs I'm railing against. If a stored procedure defined a temporary, reusuable function, SQL has all of the information necessary to optimize execution plans accordingly.

It's a habit you get into because sql server gets confused by ambiguous syntax.

Which again goes to the root of the problem that SQL as a language isn't all that great. Having to include "optional" language constructs to massage the parser into accepting your code is indicative of a poor language, or at the very least a language whose features added over the years are trying to turn the language into something it's not.

I refuse to accept that for a data query and manipulation language SQL is the best we can do. It is very, very good at the database operations you'd expect--selects, inserts, updates, deletes, and their more complicated variants. The second you need to do something other than select/insert/update/delete operations the language very quickly falls apart.