4 ms·
Wow, we have different definitions of Joy... I always treated PL/SQL as a necessary evil for performing specialized atomic operations, or merges, or other such
by bluejekyll 9y ago
Wow, we have different definitions of Joy...
I always treated PL/SQL as a necessary evil for performing specialized atomic operations, or merges, or other such things where SQL wasn't enough. I never enjoyed it, but I had to do it.
I'm very tempted to see about taking something like this, https://github.com/thehydroimpulse/postgres-extension.rs https://github.com/thehydroimpulse/postgres-extension.rs, and using a language I actually like. That example needs to be updated, but seems pretty straight-forward.
Edit:
It would be amazing to have a rich library in Rust that could be using to write DB extensions as a replacement for pgsql, etc. There aren't that many things that need to be wrapped in the API from Postgres: https://www.postgresql.org/docs/10/static/xfunc-c.htm https://www.postgresql.org/docs/10/static/xfunc-c.htm
- pjmlp 9y agoI prefer to do database work on the database, instead of wasting network traffic with useless data. Never was into a project where the overhead of writing DB independent code was worthwhile. Usually moving to another DB meant rewriting big portions of the application anyway. Stored procedures are also a good escape hatch for some of the ORM limitations regarding SQL capabilities.
- bluejekyll 9y agoI think you misunderstood my post. I want stored procedures too, bc they are necessary in certain cases. But I want them in a language I like. The repo I linked to is for C based extensions added to Postgres but written in Rust, that could replace pgsql for stored procedures.
- pjmlp 9y agoI did understood that, but unless the language has 1:1 of SQL declarative power, it is a no go for the majority of DBAs. Hence why Perl, Java, .NET as stored procedures have been a failure to SQL extensions.
- bluejekyll 9y agoAh. Now that’s a challenge...
- rbanffy 9y agoThat's a cultural problem, not a technical one.
- rbanffy 9y agoRunning code wherever the database thinks is best is a nice thing, but nothing really prevents it from being implemented in a more flexible language than something built on top of SQL. SQL is powerful, but it's a DSL.