3 ms·
tl;dr: SQL hates you and it's your fault it hates you. to elaborate: I'm rapidly appreciating that SQL is a "bondage and discipline" language where it is impos
by Pxtl 3y ago
tl;dr: SQL hates you and it's your fault it hates you.
to elaborate: I'm rapidly appreciating that SQL is a "bondage and discipline" language where it is impossible for SQL to fail at any given task, it can only be failed by its users/developers.
edit: further, it occurs to me also that SQL hates you because in a sane language you'd be able to write up some generic method that says "compare every element of these collections to each other" that was reusable for all possible collections. But try defining a scalar user-defined function that takes two arbitrary resultsets as parameters. But not only can I not do that, I'm a bad person for wanting that because it violates Relational Theory.
- BrentBrewington 3y agoYou should definitely check out dbt :) Some links in my comment: https://news.ycombinator.com/item?id=36911937 https://news.ycombinator.com/item?id=36911937
- tremon 3y agobecause it violates Relational Theory It doesn't violate relational theory at all -- it merely violates the query compiler's requirements about what must be known at the time of query compilation. You can absolute write a query that does what you want (you need a stored procedure that generates ad-hoc functions based on the involved tables' signatures), but stored sql objects must have defined inputs and outputs. What you're asking for is a meta-sql function that can translate to different query plans based on its inputs, and that's not allowed because its performance cannot be predetermined.
- Pxtl 3y agoC has had this problem solved with preprocessor macros for 50 years.