On Wed, Sep 3, 2014 at 7:54 AM, Pavel Stehule <pavel.stehule@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.