Re: PL/pgSQL 2

2014-09-01 20:23 GMT+02:00 Joel Jacobson <joel(at)trustly(dot)com>:

> On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > What is actually being proposed, AFAICS, is a one-shot fix for a bunch
> > of unfortunate choices. That might be worth doing, but let's not fool
> > ourselves about whether it's one-shot or not.
>
> I'm glad to hear you think it *might* be worth doing.
> A one-shot is exactly what it is, like a new major version of postgres
> itself (but a new major version of postgres has a much longer release
> note of changes :).
> Once released, there is obviously no way to include new non-backwards
> compatible code in future minor versions.
>
> I guess it boils down to if the project can agree on if there are any
> significant *important* changes worth doing that are *not* possible or
> feasible to implement in plpgsql.
>
> I see two possible approaches of a plpgsql2 project, both aiming to
> require minimal/no changes of most existing best-practice plpgsql
> code:
> a) fork plpgsql code base and implement changes with as few lines of
> code as possible, making it easier to understand the changes, verify
> their correctness and apply future patches of the plpgsql code.
> b) fork plpgsql code and remove as much code as possible thanks to the
> reduced complexity possible thanks to the stricter behaviour achieved
> by removing settings and enforcing a stricter coding convention and
> killing obsolete quirks.
>
>
I don't like a idea so we will have plpgsql 2x

without significant redesign you don't throw too much lines. If you really
need to design new language, then redesign engine first.

> Given plpgsql2 is a one-shot, the time window to gather input of what
> non-compatible changes to include probably needs to be at least a
> year.
> During that period, the mostly-compatible changes discussed could be
> implemented, which are the ones I'm personally most interested in
> anyway, but if we are creating a new language, then naturally we
> should take the chance to include all important changes we wish we
> could do but cannot with plpgsql.
>