On 09/02/2014 08:09 AM, Neil Tiffin wrote: > Now I could use other languages as was suggested upstream. Lets see, I use R > all the time, but R is not a first class language, not in core, and its slow. > Python 3 would be acceptable to me, but its untrusted. tcl I don’t know and > don’t want to learn as no one else seems to use it (in my world anyway). > perl is the only possibility left and again, no one in my world is using Perl > and it’s not clear if there is a performance penalty. The docs say the best > language for performance is PL/pgSQL after pure SQL.
PL/Perl is plenty fast, FWIW. I agree that it is unfortunate that we don't have an in-core trusted "real language" PL other than PL/Perl. I am personally hoping that PL/V8 will be in a position to be adopted as "PL/JavaScript" soon, as that would be an excellent fit with how the language fashion world is currently moving - JSON and JavaScript abound. More seriously, JavaScript is also a good fit for a trusted PL. I've long favoured Lua because of the excellent embeddable runtime and security-friendly design, but it's never really got the uptake required to make it a serious contender. I'd be quite happy to see PL/JavaScript in-core. (The other obvious candidate would be PL/Ruby, but it doesn't have an untrusted variant, and AFAIK Ruby is no better than Python when it comes to supporting a secure runtime: hopeless.) > That should be enough alone to suggest postgreSQL start working on a modern, > in core, fast, fully supported language. I couldn't disagree more. If we were to implement anything, it'd be PL/PSM (http://en.wikipedia.org/wiki/SQL/PSM). I'm sure it's as bizarre and quirky as anything else the SQL committee has brought forth, but it's at least a standard(ish) language. Creating a new language when there are already many existing contenders is absolutely nonsensical. Other than PL/PSM the only thing that'd make any sense would be to *pick a suitable existing language* like Lua or JavaScript and bless it as a supported, always-available, in-core language runtime that's compiled in by default. > Of course PL/pgSQL works, but so did one-line 5k perl programs that nobody > likes today. Everything can be done in assembler, but no one suggests that > today. Today, it is all about programmer productivity. PL/pgSQL has a lot > of unnecessary stuff that sucks the life out of programmer productivity. And > this should be very much a concern of the professionals that support > PostgreSQL PL/PgSQL is how it is in part because of PL/SQL (http://en.wikipedia.org/wiki/PL/SQL) which in turn owes its heritage to Ada and Pascal. It serves an important role. I'm not going to pretend it's pretty, but -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
