Joel Jacobson <j...@trustly.com> writes:
> 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.
You lost me at "fork".
Reality is that plpgsql development is not going to stop; wherever
possible we are going to want to put new features into both languages,
and bug fixes even more so. Moreover, the size of the changes you've
suggested hardly merits a fork in the first place, and the notion that
we're going to be able to radically simplify the code base after making
them is laughable. 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
