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. 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
