Re: PL/pgSQL 2

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?

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

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.

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.

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.