None of those things (views, stored procs, functions) are part of the query language. They all involve making somewhat permanent alterations to the structure of

None of those things (views, stored procs, functions) are part of the query language. They all involve making somewhat permanent alterations to the structure of the database, and are entirely capable of conflicting with other objects in the database. So if your query needs these things, you're now into "release management" territory. In terms of lack of linguistic abstraction, try writing a query that abstracts over what table it's to be run against, allowing choice of source data to be parameterized, without either resorting to shenanigans like passing strings of SQL fragments around to be eval'd during query execution, or writing the query in some other system such that it can then be compiled into SQL for execution.