2014-09-03 7:07 GMT+02:00 Joel Jacobson <j...@trustly.com>:

> On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus <j...@agliodbs.com> wrote:
> > On 09/01/2014 02:04 AM, Joel Jacobson wrote:
> >> Please share your wish list of things you would want in plpgsql2 which
> >> are not possible to implement in plpgsql because they could possibly
> >> break compatibility.
> >
> > Well, if I were designing a new procedural SQL extension language, I
> > wouldn't base it on the bastard child of ADA and SQL89.  I would come up
> > with something new.  One of the critical features such a new language
> > would have would be the ability to dynamically generate queries
> > *without* using string manipulation and EXECUTE.
> >
> > Otherwise, improvements to PL/pgSQL amount to the proverbial porcine
> > makeover.
> That's like if I would say "I want to repaint my house", you would
> reply "You should build a new house instead". :-)
> Though, I think I can understand your point of view here:
> 1. For a new developer who is starting out a new project from scratch,
> and is looking for a nice PL for PostgreSQL, such a language you
> are describing would be a perfect fit.
> 2. For all developers who already have large projects written in PL/pgSQL,
> and
> - don't have that many problems with the language,
> - are extremely productive in the language,
> - love the syntax,
> - trust the language,
> - would never want to get a divorce from the language,
> - but are very keen on *improving* the existing language,
> all such developers would be very interested in PL/pgSQL 2,
> but not so interested in any completely new PL.
> I fall into the second category. But I understand you are more interested
> in
> writing completely new projects than improving on your existing code,
> and that's a very valid argument for all such users.
> The main benefits I see with making PL/pgSQL 2 almost-compatible with
> PL/pgSQL,
> and by developing it inside the same code base as PL/pgSQL are the
> following:
> * Some PL/pgSQL code would compile and run in PL/pgSQL 2 without any
> modifications
> * Most PL/pgSQL code would compile and run in PL/pgSQL 2 with minor
> modifications
> * Most PL/pgSQL users would quickly be productive in the new language
> after reading the "Changes" doc.
> * The existing PL/pgSQL codebase is stable and trusted. If PL/pgSQL 2
> is based on it, we will only have to understand and test the changes.
> * PL/pgSQL was released16 years ago. It has survived time and is still
> The PL for PostgreSQL. In those 16 years we have a learned a lot by
> using the language. It's time for a new version of the language.

yes, but there is minimal agreement of direction of movement. I am not
alone who are thinking so your proposal is not good for general usage.


> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to