Comment by setr
16 hours ago
The thing I’ve never understood is why SQL itself is not the target of attack. There’s already an inherent language abstraction with the planner; Postgres in theory could be the JVM with any number of languages implemented on top. Including a language that lends itself to composition and auto generation of PL functions.
ORMs are fundamentally difficult because of the mapping problem, but SQL code builders should be trivial. Auto-generating and exposing every DB functionality as a type-safe $LANG function should be trivial. Instead, they’re also accidentally difficult because building SQL is difficult.
Outside of SQL, you’ve got datalog… and that’s about it. And I guess whatever horrors the NoSQL crowd keeps coming up with
SQL engines already had have multiple languages support for stored queries for at least 30 years.
C, C++, Perl, Java, CLR at least. GraalVM was originally designed as repurposing the MaximeVM ideas into a new Oracle SP engine.
You can even use Oracle or SQL Server as application server, having a Web frontend calling into stored procedures exposed as API endpoints.
agreed! I feel like basic ocaml syntax would map very well to a higher level SQL - `let` to define reusable subexpressions, `let ... in` to define inline pieces of a large query, partial application to fill in variable values, and a final function call to execute the query.