9 ms·

I don't understand the need for libraries that abstract away SQL when you could just write SQL directly and have full access to the power of the language which

by lkuty 3y ago

I don't understand the need for libraries that abstract away SQL when you could just write SQL directly and have full access to the power of the language which is quite rich (recursive CTE, windowing, ... aka Modern SQL). You could also use stored procedures/functions for more complex stuff and e.g. JSON (or native types) to transfer data between the database and the application. Why limit ourselves with a sub-optimal language be it PRQL, Ecto, other ORMs, ... ?

murkt 3y ago
PRQL is not an ORM in any kind of way, it’s the less quirky SQL, basically.
davedx 3y ago
SQL is pretty great, but for some things (I thought the example in the readme was decent) it can be quite cumbersome. Stored procedures are very imperative (and hard to debug, depending on the platform IME). This seems like a more functional approach to stored procedures. I don't think it's suggested that this replaces SQL. Use the right tool (and abstraction) for the job?
- lkuty 3y ago
  Maybe. I already think in terms of transformations (relational algebra and its closure property) when I write SQL and use a lot of CTEs. But I guess the functional way might help people see what's going on.
- CuriouslyC 3y ago
  I think the debuggability is the #1 issue with database-as-a-platform. Using notices to debug functions is such a poor workflow that even though I'm bullish on putting stuff in PG I avoid writing complex code might need to be debugged as an integrated unit.
hosteur 3y ago
SQL is incompatible with many types of autocompletion. For example columns in a select statement are not known here you write FROM. This alone justifies PRQL in my opinion.
- CuriouslyC 3y ago
  There are tools in most languages to deal with this. For example, take https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/. It introspects your database schema to generate types, and gives you autocompletion inside tagged template strings.
- nwatson 3y ago
  Jetbrains tools (Datagrip, IntelliJ IDEA, PyCharm) deal well with this if you leave a placeholder column before FROM, and write the FROM part with proper joins. You can go back to the columns and autocomplete goes just fine. You can amend our extended any part and the autocomplete logic adapts well.
- da_chicken 3y ago
  It's not a real problem in a practical sense. Yes, you have to write the FROM clause before autocomplete happens even though the SELECT must appear before it. Fortunately, however, text editiors used as IDEs allow for out-of-sequence code editing. You can just enter the FROM and move back to complete the SELECT. It's like complaining that you have to know the variable name you're going to assign something to before you start writing the expression that will set the value. int y = x * 2; The idea is to evaluate the expression and store it, but the expression doesn't actually read that way left-to-right. Wouldn't it make more sense for it to be: x * 2 assign to new int y; Technically, that's written more in execution order. In practice it just isn't that big of a deal. It only trips up beginners.
snthpy 3y ago
This comes up every time PRQL makes it onto HackerNews and is a fair question: Short answer: DX Slightly longer answer: Developer productivity and experience, especially for EDA and interactively writing complex analytical queries. Most people that have tried PRQL just find it more convenient to write their analytical queries in it. PRQL compiles to SQL so it can't express anything you can't already do in SQL, but you can probably express yourself much faster in PRQL. Just try the following query in the online PRQL Playground (https://prql-lang.org/playground/ https://prql-lang.org/playground/) to find the longest track per album: ```prql from tracks group album_id ( sort {-milliseconds} take 1 ) ``` How long would it take you to write the SQL for that? Disclaimer: I'm a PRQL contributor.
- hans_castorp 3y ago
  > How long would it take you to write the SQL for that? select distinct on (album_id) * from tracks order by album_id, milliseconds desc;
  - dewey 3y ago
    With the additional benefit that resources about SQL are everywhere and every question has been answered already multiple times. On top of that you are most likely to encounter SQL at a job than PRQL.
    - deleted 3y ago
      [deleted]
  - hobs 3y ago
    You'd also need a LIMIT or a TOP, and you might need a subquery for that depending on your SQL of choice.
    - hans_castorp 3y ago
      The question was "the longest track per album", so I'd expect one row per album as the result (which is what my query does). But adding a LIMIT would not do that. It might be that the question was "the longest track across all albums" which indeed would require a LIMIT
baq 3y ago
> Why limit ourselves with a sub-optimal language be it PRQL? Actually why limit yourself with SQL...? PRQL is a language compiled into SQL and makes certain hard-to-do things in SQL easy purely because it allows to streamline operations which SQL needs CTE joins or whatever hoop jumping to solve. My favorite example which sounds easy but isn't - select the row which is MAX(...).
- ttfkam 3y ago
  > Actually why limit yourself with SQL...? Because it's everywhere, has extensive documentation and tutorials, all database tools support it, all relational engines support it, some non-relational engines support it, all programming languages have library support for it, it can be accessed through command line tools as well as graphical interfaces, etc. You think an industry is going to give up 50 years of infrastructure because some (typically junior) devs think the syntax is "kinda icky"? > My favorite example which sound easy but isn't - select the row which is MAX(...). If you look earlier in the comments you will see queries that have "DISTINCT ON" in them. It solves the problem that sounds easy, but actually is pretty easy if you know SQL.
  - jeroen79 3y ago
    I agree, sql is well documented and an industry standard, no need to make it more complex by adding preprocessors that do nothing but change the syntax. Just bite in and learn proper sql.
    - ttfkam 3y ago
      I would love relational database engines to adopt the same syntax when they support a feature. There is no compelling business case for them to do so though. Browsers converged largely in response to IE's dominance. If Firefox, Safari, and Opera had each gone their own way, no single one of them could ever get enough marketshare to get developers to care. Together they made a block significant enough that Microsoft was forced to join in or die. (Actually did effectively die once Edge was moved to the Blink engine. Now it's a satellite of a mostly standards-compliant effort.) But databases aren't browsers. Devs just have a single target usually: whatever database engine the company decided to use. Still it would be nice to have greater overlap to reduce the niggling details between them that only seem to exist today due to inertia rather than technical necessity.
vendiddy 3y ago
The thing I hate most about SQL is lack of composability. In most languages it's easy to pull out functions. In SQL you end up with a giant hard to comprehend mess. I think the underlying relational concepts in SQL are sound but I'd love to see ideas like PRQL that aim make SQL easier to write and maintain. Stored procedures and functions are nice but don't allow the basic idea of breaking a large query apart into smaller logical components.
- CuriouslyC 3y ago
  Your statement about breaking large queries apart is wrong. You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. SQL is just as composable as any other language. The thing that's lacking right now is the tooling for managing/testing/deploying database code. There are solutions out there and the supabase folks have been working to make things better but database first development still has some hurdles in terms of DX.
  - jpgvm 3y ago
    One issue with functions though is that they can change performance in unpredictable ways. For example a colleague of mine recently altered a function I had written that was used in multiple hot-path queries. The change he made accidentally caused the function to no longer be inline-able on PostgreSQL. Once the function couldn't be inlined then the PostgreSQL planner wasn't able to select the appropriate indices and the performance of several of the queries exploded by about 100x. So while it's true it can be composed etc the current state of the art planners struggle except under very simple/constrained scenarios.
    - CuriouslyC 3y ago
      If a function is marked stable it should not impact the query plan at all, since stable functions are essentially in-lined before planning. If logic is unstable a view is probably going to be a better abstraction than a function.
haspok 3y ago
One notable reason is being database-agnostic. Like ORM's, if you can generate SQL you can generate database-specific SQL as well. SQL is also quite verbose in places (JOINs are the most trivial example), and lack a decent amount of abstraction (CTEs are relatively low level). Updating a large set of FK'd tables can be a nightmare (this is what ORMs shine at). Finally, some modern additions are quite unreadable, Postgres' JSON syntax, for example. I'm not saying that PRQL solves any of the above, but these are all legit problems with "plain" SQL.
- ako 3y ago
  How are joins verbose? It’s pretty straight to the point: combine these 2 tables on these columns… what do you want to remove to make it less verbose?
- CuriouslyC 3y ago
  Database agnosticism is so 2010. There's very little reason to choose a DB other than postgres, and if you have a reason to choose a specific niche db you're not probably not going to be migrating away from it any time soon. CTEs are a first step in structuring queries to make them decomposable. You can extract CTEs to functions and mark them stable and it's logically equivalent to the original query.
  - haspok 3y ago
    > There's very little reason to choose a DB other than postgres Sure, if you are a startup, or write your own code. But for most people the choice of database(s) is a given, and they are not in a position to challenge that. At the end of the day, Oracle has to make a living, too...
    - ttfkam 3y ago
      From parent: > you're not probably not going to be migrating away from it any time soon. Oracle has its own optimizations and foot-guns that extend well beyond what you can represent in a database-agnostic API. And once you're on that DB, you can write DB-agnostic and have performance be relatively horrible or require a careful rewrite of your schema and stored procedures when you migrate. There is not door number three. Writing a common layer for any and all relational databases is like using a Java UI library for all operating systems. Sure, it will work, but it will have obvious shortfalls, be immediately recognizable as such to anyone familiar with the underlying platform, be inconsistent with other apps on that platform, and leave any opportunities for efficiency and performance on the floor. Say you want a pivot table. In Oracle and MS SQL, it's built in. In Postgres, it's possible but noticeably more annoying. In MySQL, it's simply not possible. How would you represent this in a database-agnostic way? And yet performing in the app layer is very much slower/less efficient. Did you know Oracle supports parallel DML for enhanced performance and lower multi-query latency? You have to intentionally use though, and neither Postgres nor MySQL support it at all. What about global temporary tables? Those especially aren't found in Postgres or MySQL and are not easily swapped into the app layer without a massive performance penalty. Per-user namespaces are yet another Oracle-ism that just doesn't translate to other DB engines, but you definitely should know about. If you're making a living from Oracle, earn your pay. Make the most of what you've got.
andix 3y ago
Because SQL can be cumbersome to write. It's often repetitive, requires nesting, aliases, and a specific order of statements.
- ttfkam 3y ago
  1. Notice language is complicated for some tasks 2. Propose newer, simpler language to take care of these 3. Newer, simpler language lacks features of original language 4. Newer language adds features, making it more complicated 5. GOTO 1
  - andix 3y ago
    That's why we stopped innovation of programming languages at C89? Why use sql at all if you can also do it in C?
    - ttfkam 3y ago
      Do you think SQL stopped at SQL-92? Arrays, JSON, CTEs, window functions, booleans, MERGE, temporal tables, regular expressions, foreign tables (aka SQL/MED), etc. SQL hasn't been sitting still, (though ORMs seem to lead folks to believe it is). Do you currently write K&R C or modern C (C11 or C17)? Don't get me wrong, I don't think SQL is perfect. Far from it. But PRQL isn't fixing the defects in SQL I care about. For example in DDL, NOT NULL should be the default rather than nullable. When I declare a column as a foreign key, I shouldn't have to specify the type again when the system already knows what the referenced type is. Then again, PRQL is for querying, not data definition, so it doesn't actually solve my biggest issue at all. SQL could perhaps be more terse. I agree with a lot of folks that FROM should have been first and SELECT near last. That's pretty uselessly subjective. The argument that it's not composable falls flat for me though. Views, CTEs, foreign tables, set-returning functions, etc. are all forms of composability within SQL. When you think in terms of sets, they all fit quite well together. If you're not thinking in sets, it doesn't belong in the database in my opinion. The underlying engines themselves have been innovating like gangbusters. Using the same wire protocol, folks can connect to a standard Postgres database, a massive CockroachDB cluster, Supabase, and all points in between without changing a client library. The same is true for MySQL, MariaDB, and PlanetScale. Time series DB? Just use SQL. Analytics? SQL. Document-oriented data? There's even standard JSON query syntax within SQL. It works. It doesn't generate huge amounts of CVEs like C has. (DB libraries have the SQL injection attacks, not SQL itself.) And it scales fairly seamlessly from Google Spanner all the way down to embedded SQLite. But folks assert it's irreparably broken and needs urgent replacement. Having trouble buying it. Perhaps I just haven't seen the right replacement yet. That may indeed be the case. I just don't see PRQL being that replacement. It feels a lot more like a lateral move to me at best, and that's just too disruptive compared to potential benefit.
adrian_b 3y ago
In my opinion SQL is the sub-optimal language. Whenever I am writing SQL I am not thinking in SQL, but I am thinking in what I consider to be the mathematical sound way, which I translate into SQL while writing. I consider thinking in SQL a much greater mental handicap than having to translate mentally into it. I would prefer to write directly in what I would consider as a good query language and have it translated automatically into SQL, for compatibility with what is, for unfortunate historical reasons, the standard. I have not attempted previously to do or use something like this, but work like that discussed here seems like a step in the right direction.
- ttfkam 3y ago
  Can you expand on this? I have always seen SQL as a DSL for set theory. How are you seeing things "mathematically" that do not comport with set manipulation in SQL?

by lkuty 3y ago

murkt 3y ago

PRQL is not an ORM in any kind of way, it’s the less quirky SQL, basically.

davedx 3y ago

SQL is pretty great, but for some things (I thought the example in the readme was decent) it can be quite cumbersome. Stored procedures are very imperative (and hard to debug, depending on the platform IME). This seems like a more functional approach to stored procedures. I don't think it's suggested that this replaces SQL. Use the right tool (and abstraction) for the job?

lkuty 3y ago
Maybe. I already think in terms of transformations (relational algebra and its closure property) when I write SQL and use a lot of CTEs. But I guess the functional way might help people see what's going on.
CuriouslyC 3y ago
I think the debuggability is the #1 issue with database-as-a-platform. Using notices to debug functions is such a poor workflow that even though I'm bullish on putting stuff in PG I avoid writing complex code might need to be debugged as an integrated unit.

hosteur 3y ago

SQL is incompatible with many types of autocompletion. For example columns in a select statement are not known here you write FROM. This alone justifies PRQL in my opinion.

CuriouslyC 3y ago
There are tools in most languages to deal with this. For example, take https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/. It introspects your database schema to generate types, and gives you autocompletion inside tagged template strings.
nwatson 3y ago
Jetbrains tools (Datagrip, IntelliJ IDEA, PyCharm) deal well with this if you leave a placeholder column before FROM, and write the FROM part with proper joins. You can go back to the columns and autocomplete goes just fine. You can amend our extended any part and the autocomplete logic adapts well.
da_chicken 3y ago
It's not a real problem in a practical sense. Yes, you have to write the FROM clause before autocomplete happens even though the SELECT must appear before it. Fortunately, however, text editiors used as IDEs allow for out-of-sequence code editing. You can just enter the FROM and move back to complete the SELECT. It's like complaining that you have to know the variable name you're going to assign something to before you start writing the expression that will set the value. int y = x * 2; The idea is to evaluate the expression and store it, but the expression doesn't actually read that way left-to-right. Wouldn't it make more sense for it to be: x * 2 assign to new int y; Technically, that's written more in execution order. In practice it just isn't that big of a deal. It only trips up beginners.

snthpy 3y ago

This comes up every time PRQL makes it onto HackerNews and is a fair question: Short answer: DX Slightly longer answer: Developer productivity and experience, especially for EDA and interactively writing complex analytical queries. Most people that have tried PRQL just find it more convenient to write their analytical queries in it. PRQL compiles to SQL so it can't express anything you can't already do in SQL, but you can probably express yourself much faster in PRQL. Just try the following query in the online PRQL Playground (https://prql-lang.org/playground/ https://prql-lang.org/playground/) to find the longest track per album: ```prql from tracks group album_id ( sort {-milliseconds} take 1 ) ``` How long would it take you to write the SQL for that? Disclaimer: I'm a PRQL contributor.

hans_castorp 3y ago
> How long would it take you to write the SQL for that? select distinct on (album_id) * from tracks order by album_id, milliseconds desc;
- dewey 3y ago
  With the additional benefit that resources about SQL are everywhere and every question has been answered already multiple times. On top of that you are most likely to encounter SQL at a job than PRQL.
  - deleted 3y ago
    [deleted]
- hobs 3y ago
  You'd also need a LIMIT or a TOP, and you might need a subquery for that depending on your SQL of choice.
  - hans_castorp 3y ago
    The question was "the longest track per album", so I'd expect one row per album as the result (which is what my query does). But adding a LIMIT would not do that. It might be that the question was "the longest track across all albums" which indeed would require a LIMIT

baq 3y ago

> Why limit ourselves with a sub-optimal language be it PRQL? Actually why limit yourself with SQL...? PRQL is a language compiled into SQL and makes certain hard-to-do things in SQL easy purely because it allows to streamline operations which SQL needs CTE joins or whatever hoop jumping to solve. My favorite example which sounds easy but isn't - select the row which is MAX(...).

ttfkam 3y ago
> Actually why limit yourself with SQL...? Because it's everywhere, has extensive documentation and tutorials, all database tools support it, all relational engines support it, some non-relational engines support it, all programming languages have library support for it, it can be accessed through command line tools as well as graphical interfaces, etc. You think an industry is going to give up 50 years of infrastructure because some (typically junior) devs think the syntax is "kinda icky"? > My favorite example which sound easy but isn't - select the row which is MAX(...). If you look earlier in the comments you will see queries that have "DISTINCT ON" in them. It solves the problem that sounds easy, but actually is pretty easy if you know SQL.
- jeroen79 3y ago
  I agree, sql is well documented and an industry standard, no need to make it more complex by adding preprocessors that do nothing but change the syntax. Just bite in and learn proper sql.
  - ttfkam 3y ago
    I would love relational database engines to adopt the same syntax when they support a feature. There is no compelling business case for them to do so though. Browsers converged largely in response to IE's dominance. If Firefox, Safari, and Opera had each gone their own way, no single one of them could ever get enough marketshare to get developers to care. Together they made a block significant enough that Microsoft was forced to join in or die. (Actually did effectively die once Edge was moved to the Blink engine. Now it's a satellite of a mostly standards-compliant effort.) But databases aren't browsers. Devs just have a single target usually: whatever database engine the company decided to use. Still it would be nice to have greater overlap to reduce the niggling details between them that only seem to exist today due to inertia rather than technical necessity.

vendiddy 3y ago

The thing I hate most about SQL is lack of composability. In most languages it's easy to pull out functions. In SQL you end up with a giant hard to comprehend mess. I think the underlying relational concepts in SQL are sound but I'd love to see ideas like PRQL that aim make SQL easier to write and maintain. Stored procedures and functions are nice but don't allow the basic idea of breaking a large query apart into smaller logical components.

CuriouslyC 3y ago
Your statement about breaking large queries apart is wrong. You can write queries with CTES to improve readability, and extract CTEs into functions that can be selected as queries get too large and unwieldly. SQL is just as composable as any other language. The thing that's lacking right now is the tooling for managing/testing/deploying database code. There are solutions out there and the supabase folks have been working to make things better but database first development still has some hurdles in terms of DX.
- jpgvm 3y ago
  One issue with functions though is that they can change performance in unpredictable ways. For example a colleague of mine recently altered a function I had written that was used in multiple hot-path queries. The change he made accidentally caused the function to no longer be inline-able on PostgreSQL. Once the function couldn't be inlined then the PostgreSQL planner wasn't able to select the appropriate indices and the performance of several of the queries exploded by about 100x. So while it's true it can be composed etc the current state of the art planners struggle except under very simple/constrained scenarios.
  - CuriouslyC 3y ago
    If a function is marked stable it should not impact the query plan at all, since stable functions are essentially in-lined before planning. If logic is unstable a view is probably going to be a better abstraction than a function.

haspok 3y ago

One notable reason is being database-agnostic. Like ORM's, if you can generate SQL you can generate database-specific SQL as well. SQL is also quite verbose in places (JOINs are the most trivial example), and lack a decent amount of abstraction (CTEs are relatively low level). Updating a large set of FK'd tables can be a nightmare (this is what ORMs shine at). Finally, some modern additions are quite unreadable, Postgres' JSON syntax, for example. I'm not saying that PRQL solves any of the above, but these are all legit problems with "plain" SQL.

ako 3y ago
How are joins verbose? It’s pretty straight to the point: combine these 2 tables on these columns… what do you want to remove to make it less verbose?
CuriouslyC 3y ago
Database agnosticism is so 2010. There's very little reason to choose a DB other than postgres, and if you have a reason to choose a specific niche db you're not probably not going to be migrating away from it any time soon. CTEs are a first step in structuring queries to make them decomposable. You can extract CTEs to functions and mark them stable and it's logically equivalent to the original query.
- haspok 3y ago
  > There's very little reason to choose a DB other than postgres Sure, if you are a startup, or write your own code. But for most people the choice of database(s) is a given, and they are not in a position to challenge that. At the end of the day, Oracle has to make a living, too...
  - ttfkam 3y ago
    From parent: > you're not probably not going to be migrating away from it any time soon. Oracle has its own optimizations and foot-guns that extend well beyond what you can represent in a database-agnostic API. And once you're on that DB, you can write DB-agnostic and have performance be relatively horrible or require a careful rewrite of your schema and stored procedures when you migrate. There is not door number three. Writing a common layer for any and all relational databases is like using a Java UI library for all operating systems. Sure, it will work, but it will have obvious shortfalls, be immediately recognizable as such to anyone familiar with the underlying platform, be inconsistent with other apps on that platform, and leave any opportunities for efficiency and performance on the floor. Say you want a pivot table. In Oracle and MS SQL, it's built in. In Postgres, it's possible but noticeably more annoying. In MySQL, it's simply not possible. How would you represent this in a database-agnostic way? And yet performing in the app layer is very much slower/less efficient. Did you know Oracle supports parallel DML for enhanced performance and lower multi-query latency? You have to intentionally use though, and neither Postgres nor MySQL support it at all. What about global temporary tables? Those especially aren't found in Postgres or MySQL and are not easily swapped into the app layer without a massive performance penalty. Per-user namespaces are yet another Oracle-ism that just doesn't translate to other DB engines, but you definitely should know about. If you're making a living from Oracle, earn your pay. Make the most of what you've got.

andix 3y ago

Because SQL can be cumbersome to write. It's often repetitive, requires nesting, aliases, and a specific order of statements.

ttfkam 3y ago
1. Notice language is complicated for some tasks 2. Propose newer, simpler language to take care of these 3. Newer, simpler language lacks features of original language 4. Newer language adds features, making it more complicated 5. GOTO 1
- andix 3y ago
  That's why we stopped innovation of programming languages at C89? Why use sql at all if you can also do it in C?
  - ttfkam 3y ago
    Do you think SQL stopped at SQL-92? Arrays, JSON, CTEs, window functions, booleans, MERGE, temporal tables, regular expressions, foreign tables (aka SQL/MED), etc. SQL hasn't been sitting still, (though ORMs seem to lead folks to believe it is). Do you currently write K&R C or modern C (C11 or C17)? Don't get me wrong, I don't think SQL is perfect. Far from it. But PRQL isn't fixing the defects in SQL I care about. For example in DDL, NOT NULL should be the default rather than nullable. When I declare a column as a foreign key, I shouldn't have to specify the type again when the system already knows what the referenced type is. Then again, PRQL is for querying, not data definition, so it doesn't actually solve my biggest issue at all. SQL could perhaps be more terse. I agree with a lot of folks that FROM should have been first and SELECT near last. That's pretty uselessly subjective. The argument that it's not composable falls flat for me though. Views, CTEs, foreign tables, set-returning functions, etc. are all forms of composability within SQL. When you think in terms of sets, they all fit quite well together. If you're not thinking in sets, it doesn't belong in the database in my opinion. The underlying engines themselves have been innovating like gangbusters. Using the same wire protocol, folks can connect to a standard Postgres database, a massive CockroachDB cluster, Supabase, and all points in between without changing a client library. The same is true for MySQL, MariaDB, and PlanetScale. Time series DB? Just use SQL. Analytics? SQL. Document-oriented data? There's even standard JSON query syntax within SQL. It works. It doesn't generate huge amounts of CVEs like C has. (DB libraries have the SQL injection attacks, not SQL itself.) And it scales fairly seamlessly from Google Spanner all the way down to embedded SQLite. But folks assert it's irreparably broken and needs urgent replacement. Having trouble buying it. Perhaps I just haven't seen the right replacement yet. That may indeed be the case. I just don't see PRQL being that replacement. It feels a lot more like a lateral move to me at best, and that's just too disruptive compared to potential benefit.

adrian_b 3y ago

In my opinion SQL is the sub-optimal language. Whenever I am writing SQL I am not thinking in SQL, but I am thinking in what I consider to be the mathematical sound way, which I translate into SQL while writing. I consider thinking in SQL a much greater mental handicap than having to translate mentally into it. I would prefer to write directly in what I would consider as a good query language and have it translated automatically into SQL, for compatibility with what is, for unfortunate historical reasons, the standard. I have not attempted previously to do or use something like this, but work like that discussed here seems like a step in the right direction.

ttfkam 3y ago
Can you expand on this? I have always seen SQL as a DSL for set theory. How are you seeing things "mathematically" that do not comport with set manipulation in SQL?