2014-09-01 14:27 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule <pavel.steh...@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. > > 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
