Re: PL/pgSQL 2

2014-09-02 14:38 GMT+02:00 Andrew Dunstan <andrew(at)dunslane(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>