2014-09-01 20:23 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane <t...@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. >
