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