Re: PL/pgSQL 2

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.

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

>
> It *would* be a problem if you had to choose between writing all
> functions in their plpgsql or plpgsql2, but thanks to postgres support
> for different pl-languages and mixing different languages in the same
> project, I cannot see the problem.
>
> > implementation of SQL/PSM .. it is new language .. based on relative good
> > ANSI SQL specification without compatibility issues
> > reimplementation plpgsql based on new API .. it should to significantly
> > reduce size
>
> 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.

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

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

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

>
> I think the main difference in what is possible with plpgsql2 compared
> to improvements of plpgsql,
> boil down to not having to evaluate any proposed change against "could
> this break compatibility in theory?"
> but instead "will this most certainly break compatilibity for most users?".
>
> Today, if a proposed code change in plpgsql would have an impact >0%,
> the change is rejected.
>

because it was useless - it was not any new value.

> With plpgsql2, maybe we could allow an impact of <X% of lines of code.
>
> 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.

Pavel