Re: PL/pgSQL 2

On 9/1/14 2:53 PM, Pavel Stehule wrote:
> 2014-09-01 14:27 GMT+02:00 Joel Jacobson <joel@trustly.com>:
>
>> On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.stehule@gmail.com>
>> wrote:
>>> I agree with Andres - it is not a good for plpgsql and for plpgsql users.
>>> The benefit must be significant for 90% of users.
>> ...
>>> Official implementation of plpgsql2 can be very wrong and dangerous
>> signal -
>>> so we should not to do.
>>
>> Do you argue the introduction of plpgsql2 would hurt the users of
>> plpgsql in some way? How?
>>
>
> yes, anybody who has thousands lines in plpgsql will be messy, when we
> publish so there will be new not fully compatible plpgsql2.

That's a good thing.  PL/PgSQL is broken in various subtle ways.

>>
>> If you have X% who continue to happily use plpgsql, and (100-X%) who
>> find they can use plpgsql2 in their project, for new functions or all
>> functions (for a new project), then you have made (100-X)% of the
>> users more happy, than they would be if they were forced to use
>> plpgsql and suffer from its problems.
>>
>
> It bad signal to have two languages plpgsql and plpgsql2. Who will believe
> to us so we will continue development of plpgsql?

I think what should happen is that we stop adding features to plpgsql. 
We should design plpgsql2 in such a way that it's easier to add new 
features to it in the future (to the extent that that's possible), and 
then add the new stuff only to that one.

>> A new language like SQL/PSM would be helpful for new projects,
>> but personally I have a huge code base written in plpgsql which
>> I would at some point want to port to plpgsql2, and the least time
>> consuming
>> way of doing so would be to make sure most existing plpgsql-functions
>> require no modifications at all to work with plpgsql2.
>>
>
> I understand - just I don't would to repeat a issues of Python3 or Perl6 or
> ..
>
> I don't believe so people understand different casting rules in almost all
> same language plpgsql and plpgsql2. So it is one reason why start from zero
> with less know syntax.

I'm not convinced.  Seems to me that it would be better in every way to 
just fix the familiar syntax.

> More I don't feel a real request from users.

Yeah, that's the problem with subtle problems: only people who use the 
language a lot and pay attention are going to notice them.

>> A new language would mean I would have to rewrite all functions,
>> which is much worse than doing no or minor modifications to existing
>> functions.
>>
>>> otherwise plpgsql2 is wrong name .. with respect to your goals it should
>> be
>>> "stricter plpgsql"
>>
>> I think plpgsql2 is a perfect name for it, because it is a new version
>> of plpgsql,
>> based on all the empirical knowledge gained from the 16 years of
>> development in plpgsql.
>> And while most improvements fall in the "stricter" category, there are
>> probably other things
>> which we would want to change when having the possibility of breaking
>> compatibility.
>>
>
> you can do it - but will be better as independent project.
>
> There is big space for improvement  in plpgsql - but almost all can be done
> without some stronger incompatibility.

That's very very general and it would depend on the details, but I still 
disagree in general.

> Or this incompatibility (or stronger restrictivity) can be introduced in
> longer time window.

I'd think that that would be worse for the current users of PL/PgSQL, 
not better.

>> If greater than X%, users will think it's unrealistic to port all
>> their code from plpgsql to plpgsql2,
>> which might be a long-term realistic requirement for some users,
>> especially for the project,
>> as in Y years from now, maybe the development of plpgsql can be put to
>> halt,
>> to avoid having to maintain both code bases, which *is* undoubtably an
>> increased workload for the project.
>>
>> Also, all your work and effort with plpgsql_check_function() would be
>> a natural fit for plpgsql2,
>> the problems it detect should of course be errors by default in the
>> language.
>>
>
> plpgsql_check is necessary because we don't would to introduce strong
> dependency between functions and database schema. It is 70% motivation.
>
> Next 30% can be integrated to language well. And I believe if PL engine was
> more friendly to extensions, it can be 80% less code.

Yeah, PL/PgSQL is a bit hostile to to extensions like plpgsql_check. 
But that doesn't mean that we have to bin everything we have and start 
from scratch.


.marko