Comment by pjmlp
3 months ago
Actually it is my favourite stored procedured programming language, nothing else comes close to it in capabilities, or tooling.
Transact SQL is a close second, thanks to the tooling, but not as great as language, still better than the alternatives.
pgSQL has the plus of being similar to PL/SQL, but it is neither as feature rich, nor in tooling.
Everything else is even worse.
Do you actually mean that sincerely or is this just another occasion that you’re taking an opposing view just for giggles?
Because given your past comments favouring Java and my experience with both those languages, I’m very surprised you’d pick PL/SQL over SQL/JRT.
The issue with stuff like SQL/JRT is that often stored procs are just running a few SQL statements in a row, the stored procs are being used for security or latency optimization but not because there's some truly complex logic. And if you want a language that has the basics like variables, loops, conditionals, data structures etc but which also makes issuing SQL statements natural, then it's hard to beat PL/SQL.
I really mean that, all those approaches using Perl, Java, .NET as stored procedures never gained much love among DBAs or the market in general, and I always favour approaches where I am not the only person on the building that can change something.
Also those approaches lack the end to end tooling, so you're basically back at printf debugging.
That’s a fair point though it’s more of a practical argument when the topic was more academic discussion with regards to language design.
But I do agree that practical considerations are important when making architectural decisions.
5 replies →