Re: PL/pgSQL 2 - Mailing list pgsql-hackers

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