Re: PL/pgSQL 2

2014-09-01 15:12 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:

> On 9/1/14 2:53 PM, Pavel Stehule wrote:
>
>> 2014-09-01 14:27 GMT+02:00 Joel Jacobson <joel(at)trustly(dot)com>:
>>
>> On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.

I am sorry. Users around me are allergic on any +X language, so I am
careful.

I understand to you, understand to your motivation, but I disagree with
your proposal.

We can talk about possibility to design a extensions, what you need

and we can redesign plpgsql engine to allow to different setup for any
specific usage (with extensions, some config).

But still I would to respect some relation to PL/SQL and ADA (not necessary
compatibility).

Regards

Pavel

>
>
> 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
>