> You can't "statically syntax check" a dynamically built query. In a language with any sort of decent static type system, you most assuredly can. There should

> You can't "statically syntax check" a dynamically built query. In a language with any sort of decent static type system, you most assuredly can. There should be no way to build and use an invalid query, the same as you can use the type system to enforce any other constraints. > It's one thing to use a query builder for those rare complicated dynamic queries, but an entirely different thing to lock down and hide the connection and have your hands at the mercy of an abstraction layer for your every query. Almost any SQL I've written has needed to be composable, for the same reasons that any other code should be composable. I need to be able to get <X> complex set of data from the database, given an identifier which could be an ID, or an URL slug, or any number of other things. I may also need to get that either for one row or for many. It's nice to be able to split that up into the bit of the query that selects the data, and the bit of the query that chooses which row(s) to select it from, without writing out the SQL twice or developing "stringly-typed" code. It's a standard across most of the software development world that when dealing with source code (which SQL is), you almost always work with ASTs. The frameworks I use for this do allow me complete access to the database, including all the things you've mentioned, and the ability to extend my queries with arbitrary syntax.