3 ms·
See Haskell's Esqueleto, Scala's Slick and Quill, C#/F#'s LINQ to SQL + Type Providers, probably others. In the case of Haskell and Scala the aforementioned qu
by virtualwhys 8y ago
See Haskell's Esqueleto, Scala's Slick and Quill, C#/F#'s LINQ to SQL + Type Providers, probably others.
In the case of Haskell and Scala the aforementioned query DSLs serve as CTE generators without the performance hit (albeit non-recursive).
Being able to compose complex statements based on statically typed query snippets is really, really nice -- strips out the reams of repeated boilerplate that one inevitably is forced to write with string-y SQL.
- amelius 8y agoInteresting. Could these be extended to support recursion using these new recursive CTEs? Or would they miss some fundamental mechanism, such as the ability to pass parameters down the recursive queries?
- virtualwhys 8y ago> Could these be extended to support recursion using these new recursive CTEs? Sure, in the end they generate (prepared) sql statements; CTEs are just another statement with an expected result type. As for supporting parameters in a recursive CTE, I don't think providing runtime values would be an issue. WITH RECURSIVE $name (n) AS ( SELECT $init UNION ALL SELECT n + $incr FROM $name WHERE n + $incr <= $limit ) SELECT n FROM $name; Could use it right now with built-in string interpolator, but not sure how this would look in DSL form since recursive CTEs can support both real and temporary tables (i.e. the DSL has to know the structure of the temporary table in order to statically determine the result type of the query).