2014-09-01 15:12 GMT+02:00 Marko Tiikkaja <ma...@joh.to>: > On 9/1/14 2:53 PM, Pavel Stehule wrote: > >> 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. >> > > 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 >
