On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane <tgl@sss.pgh.pa.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.
