2014-09-02 14:38 GMT+02:00 Andrew Dunstan <and...@dunslane.net>: > > On 09/02/2014 05:44 AM, Álvaro Hernández Tortosa wrote: > >> >> On 02/09/14 11:34, Mark Kirkwood wrote: >> >>> On 02/09/14 21:25, Álvaro Hernández Tortosa wrote: >>> >>>> >>>> On 02/09/14 05:24, Craig Ringer wrote: >>>> >>>>> 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. >>>>> >>>> So we'd choose a bizarre and quirky language instead of anything >>>> better just because it's standard. I'm sure current and prospective >>>> users will surely prefer a bizarre and quirky language that is standard >>>> approved, rather than a modern, comfortable, easy-to-use, that is not >>>> embodied by the ISO. No doubt ^_^ >>>> >>>> >>> Well there is the risk that by randomly adding new syntax to PL/pgSQL we >>> turn it in a bizarre and quirky *non standard* language. Part of the >>> attraction of PL/pgsql is that it is Ada like - if we break that too much >>> then...well...that would be bad. So I think a careful balance is needed, to >>> add new features that keep the spirit of the original language. >>> >>> >> I agree. I think I haven't suggested adding new syntax to pl/pgsql. >> But having its syntax similar to ADA is IMHO not something good. I'm sure >> few prospective postgres users would be compelled to that. They are >> compelled about JavaScript, python, Scala or Ruby, to name a few, but >> definitely not ADA. >> > > > Just as a small nit pick - the name of the language is not ADA, but Ada. > It isn't an acronym. The language is named after Ada Lovelace, arguably the > world's first programmer. If you're not familiar with modern Ada, let me > recommend the newly published "Programming in Ada 2012" by John Barnes. But > I digress. > > JavaScript would actually be quite a good alternative. However, using it > involves something others have objected to, namely calling SQL via a > function call. It's true that plpgsql lets you call SQL commands without > explicitly invoking SPI. OTOH, it actually relies on SPI under the hood a > lot more that other PLs, which I have little doubt is responsible for > timings like this: > > andrew=# do $$ declare x int = 1; i int = 1; begin while i < > 10000000 loop i := i + 1; x := x + 46; end loop; raise notice ' x = > %',x; end; $$; > NOTICE: x = 459999955 > DO > Time: 13222.195 ms > andrew=# do $$ var x = 1; var i = 1; while (i < 10000000) { i += 1; > x += 46; } plv8.elog(NOTICE, "x = " + x); $$ language plv8; > NOTICE: x = 459999955 > DO > Time: 27.976 ms >
this test is unfair to plpgsql, and you know it well :) any operations over native types will be faster than in plpgsql, although this difference is maybe too much. Doesn't use --enable-cassert ? > > But I'm not suggesting we should implement a Javascript PL in core either. > > Finally, +1 to Tom's suggestion upthread that we implement different > behaviours via pragmas rather than some new offshoot language. Maybe a GUC > could specify a default set of such pragmas, so you wouldn't need to > decorate every function with them. > > cheers > > andrew > > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >