/tech/ - Technology

>>29455
any change to SQL is dead in the water as its got too much inertia to change since the 1970s. I mean something like object SQL where you could add cardinality to foreign key relations might be good (similar to java spring jpa/hibernate objects), but it aint gonna happen.

Most people have made their peace with SQL as dumb storage and anything like what the blog author describes can be done with LINQ for C# and JOOQ for java.

>>29455
This is already possible with libraries like Quill and Protoquill, if I'm not mistaken. They compile to regular SQL at compile time, which is inspectable and type safe.

>>29471
This is an addition though, not a rework from scratch, and things are still being added to the various dialects. I don't see why they couldn't standardize this proposal (or something along the same lines)

>>29474
Many reasons. One easy reason is that it's very complicated to implement natively. The benefits are not immediately apparent.
Who would be using this exactly?

Regarding making this standard, that's basically a no-go. There's too many SQL implementations that rely on the absolute simplicity of SQL. Adding such a complicated feature would essentially mean that breaking ANSI SQL would be necessary to keep the DB working as intended. See for example SQLite.

And on top, as mentioned, this already exists in functional SQL libraries. The applications are rather limited even then.

>>29475
> The benefits are not immediately apparent.
There's an entire article to explain the case https://borretti.me/article/composable-sql
As for the others, I kinda doubt it would add much more complexity, we already have functions and views

>>29473
That's lloks like an ORM, and isn't really what the article is trying to solve with the proposal

>>29474
>This is an addition though, not a rework from scratch
again, doesnt matter. SQL is like C - it never changes and if it did it would break a bunch of shit that depends on it not changing. you even have things going the other direction with nosql databases making sql-like syntax, even kafka has ksql. I mean like other anons here have said if you need more complicated shit its better to do that at the application level rather that in the query.

>>29480
C changes all the time, its latest version, C23, was published in October 2024.

>>29480
They added a bunch of shit in C11 and C23. Adding is not removing.

>>29489
Generally the way to get extensions into sql involves getting it into either Postgres, MySQL and sqlite and hoping the other vendors pick it up, or doing a port yourself

>>29490
SQLite is basically impossible as far as I know

>>29489
>They added a bunch of shit in C11 and C23

yeah but its not really THAT different. the changes are extremely minor.

>>29493
wym?

write your own sqlite implementation with these features. it sounds intimidating but it is not, the logic behind it is very simple
https://blog.sylver.dev/build-your-own-sqlite-part-1-listing-tables

>>29497
>>29499
They don't accept patches from outside their circle. You need to be approved by the devs before you can even contribute with your code.

why do FP lovers always want to generalize the most random shit, like this, and why do they always want someone else to implement the stuff they want?

>>29506
Testing. The other complaint is true tho

>>29500
? I'm saying you can write your own sqlite -type database, you don't have to go through the sqlite bureaucracy. that blog entry is a really beginner friendly introduction to database design. hell, I'm pretty sure you could easily write something better and more composable than sqlite just by using non-blocking i/o (so it could be integrated into event loops like libuv), I'm sure someone must have already done this