Yes, SQL's biggest fault is that it's not very composable. Complex queries end up being long and repetitive, and the order of the parts of a query is totally unintuitive (it should go something like: FROM, GROUP BY, SELECT, ORDER BY rather than SELECT, FROM, GROUP BY, ORDER BY, which makes autocompletion hard).

QUEL[1] was like that, but thanks to Oracle SQL won.

[1] https://en.wikipedia.org/wiki/QUEL_query_languages

One thing I never understood is that the SQL language, and its alternatives, share the same theoretical IR -- the relational algebra -- it shouldn't be that difficult to implement for postgres/mysql alternative relational languages like QUEL or Datalog. Or even just a simplified SQL with a sane, consistent syntax.

I know PG has a bunch of procedural-language alternatives, but afaik, no relational-language alternatives.

At the same time, I'd also expect it to not be that difficult to transpile from say mysql to postgres, yet there's very little in that space, at least in open source (there is however many ORMS that map to either mysql or postgres..)

Both of which, amongst the procedural-languages, you'd find a hundred transpilers (JS->C) and VM-languages (Clojure,Scala,etc on jvm) implemented even by bored/curious students. Which makes my suspicion that there's no technical blocker, just a cultural one.

That is, QUEL losing to SQL, such that you can't find any implementation, is an absurd concept -- it should be available on postgres (perhaps requiring some special starting keyword) -- but somehow it is not.

The original query language for Postgres95 was QUEL.

libpq refers to PostQUEL.

Ingres became Post-Ingres which became POSTGRES which became Postgres95 which became PostgreSQL.

https://www.postgresql.org/docs/12/history.html

CTEs can help a bit with composition (and readability)