My point is that in most other languages, this kind of functionality can easily be factored into libraries available to the community. SQL doesn't have the composability so every single of these features requires to be added directly into the language. Libraries and package tooling is practically non-existent in SQL land.

Actually some do, but…

- non standard sql

- not concise

- has limitations

- installing a function is a db migration

I had dreams. A lot of them. I still do some times.

“Normal language” functions accept/return: primitives, objects(, functions, types).

Sql functions could accept/return: scalars/primitives, a row, set of rows, a table (maybe set of tables or related rows), for aggregating functions need to group by some columns, sliding window functions need to keep track of the window.

Let’s add some kind of interfaces/traits and generics.

If we are extending current sql, then I’m certain there will be corners cases for various clauses sql clauses (select, from, on, where)

And all of that on top of basic sqls (sel/ins, checks, access controls, query execution planning)

Quite quickly c++ starts to look like an exercise in language minimalism.