2014-09-03 9:14 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > I am not against to improve a PL/pgSQL. And I repeat, what can be done > and > > can be done early: > > > > a) ASSERT clause -- with some other modification to allow better static > > analyze of DML statements, and enforces checks in runtime. > > > > b) #option or PRAGMA clause with GUC with function scope that enforce > check > > on processed rows after any DML statement > > > > c) maybe introduction automatic variable ROW_COUNT as shortcut for GET > > DIAGNOSTICS rc = ROW_COUNT > > > > If you need more, and some users would more, then it job for new language > > really. > > You fail to illustrate *why* it's a job for a new language. > All improvements suggested above are possible with plpgsql, and *should* > be improved in plpgsql, that I agree with. >
ok, super > > But the 100% backwards-compatibiity ambition puts hard limits on > what's possible, > and if we can accept (100%-X) backwards compatibility where X is a small > number, > then so much more ideas are possible, and that's why plpgsql2 is a good > idea. > > Hopefully, most of the plpgsql2 changes can be turned on/off in > plpgsql with PRAGMA clause with GUC, > but will be more messy than a good decent default behaviour. > > I'm in favour of Tom's idea. To merely make the plpgsql2 "language" a > way of explicitly saying you want > a specific exact combination of features/beaviour/settings which we > can implemented in plpgsql's existing codebase. > > Since it was about 100 posts since Tom's post, maybe it's worth > repeating for those who missed it: > > > What I would think about is > > > >c) plpgsql and plpgsql2 are the same code base, with a small number > >of places that act differently depending on the language version. > > > >We could alternatively get the result by inventing a bunch of pragma > >declarations, or some similar notation, that control the behavioral > >changes one-at-a-time. That might even be worth doing anyway, in > >case somebody likes some of the ideas and others not so much. But > >I'd see the language version as a convenient shorthand for enabling a > >specified collection of pretty-localized incompatible behavior changes. > >If they're not pretty localized, there's going to be a barrier to > >uptake, very comparable to the python3 analogy mentioned upthread. > > > > regards, tom lane > > I fully agree on this approach. It's maintainable and it will be > useful from day 1. > I can accept technical solution, but I have hard problem with your vision of plpgsql future. I afraid so it is too specific with your use case. When you use name plpgsql2 you say, so plpgsql2 is successor plpgsql. It is very hard to accept it. So any other name is not problem for me - like plpgsql-safe-subset or something else Pavel
