Re: PL/pgSQL 2 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL 2
Date
Msg-id CAFj8pRDriFkRqXj2s1pENhe7dbSFG0L5eOuoDxOsODgfO+OLFA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 2  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: PL/pgSQL 2
List pgsql-hackers



2014-09-02 14:38 GMT+02:00 Andrew Dunstan <andrew@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

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PL/PgSQL: RAISE and the number of parameters
Next
From: Andres Freund
Date:
Subject: Re: PL/pgSQL 2