Re: PL/pgSQL 2

From: Joel Jacobson <joel(at)trustly(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 2
Date: 2014-09-03 05:07:16
Message-ID: CAASwCXdn-QsWhGBZGR6W7T1_e_64MS-EsPeRYzwG8reUN8NOKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 3, 2014 at 12:19 AM, Josh Berkus <josh(at)agliodbs(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-03 05:17:48 Re: PL/pgSQL 2
Previous Message Pavel Stehule 2014-09-03 05:06:34 Re: Re: proposal: ignore null fields in not relation type composite type based constructors