From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 2 |
Date: | 2014-09-01 18:37:19 |
Message-ID: | CAFj8pRD31MZs1bSuyPOnSfc-2Gp4JC1mP27mB64=60dJXWTb3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-09-01 18:38:27 | Re: PL/pgSQL 2 |
Previous Message | Álvaro Hernández Tortosa | 2014-09-01 18:34:31 | Re: PL/pgSQL 2 |