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.
- 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.