Re: PL/pgSQL 2 - Mailing list pgsql-hackers

On Tue, Sep 2, 2014 at 5:46 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> My point is that weeks can be spent just arguing about whether you
> should have a variable-delimiter ($variable) or not, how syntax should
> look, etc. Imagine how long it'd take to get a new language syntax
> agreed upon?

I would guess about a year.

> You jumped in to say that you thought that:
>
>   EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING val;
>
> was "is exactly why we need a new language" and that "All the clumsy
> stuff we cannot fix in plpgsql, can easily be fixed in plpgsql2, with
> the most beautiful syntax we can come up with." But you haven't said HOW
> you propose to fix this one case.
>
> Show me. How do you want this to look? The user requirement is "Execute
> a SELECT against a table whose name is provided at runtime, selecting a
> column or set of columns whose names are provided at runtime, with
> literals substituted as placement parameters."
>
> The above is ugly. Fine, not arguing. Show me what you want instead.
>
>
> You're happy to say how much you dislike PL/PgSQL, but I haven't seen a
> concrete proposal on how you want something new to look. That would be a
> useful and constructive start, as we could then examine, point-by-point,
> how/if those needs can be met in PL/PgSQL. If they can't then you'd have
> a more convincing argument for a new version than "PL/PgSQL sucks".

I've *never* said PL/pgSQL sucks.
I *love* PL/pgSQL, seriously.
I write code for many hours a day in the language.
I don't even want to change much.
My wishlist consists mostly of things which makes the language more secure.
Currently it's a pain to verify your data operations do exactly what
you requested.
I would guess most novice developers don't understand this, and by
mistake write insecure code.
I don't want any OO. I don't want PL/SQL or PL/PSM. I'm a happy camper
with PL/pgSQL.

That said, *if* we now have a one-shot opportunity of possibly
breaking a bit of compatibility for a minority of current code,
motivated by the introduction of new important features not possible
without plpgsql2, *then* let's make the best of that opportunity.

I don't find myself selecting from a table which table name I don't
know the name when writing the code,
so I'm not pariticulary interested in prodiving a syntax for that use case,
but I'm not against the feature if others need it, even if it would
possibly increase the lines of code of existing plpgsql code which
needs to be modified to remain compatible by X %.

Given the needed diff between plpgsql and plpgsql2 for the changes I'm
mostly interested in would probably be quite small,
I'm in favour of Tom's suggestion of:
>c) plpgsql and plpgsql2 are the same code base, with a small number
>of places that act differently depending on the language version.

That fits perfectly for my needs, as I don't want to change much.

But even if we find we want to make larger mostly-compatible changes,
maybe that also can be implemented using the same approach.

For me, the most important is to not break *most* of existing plpgsql
code, but it's OK to break *some*.
And when breaking it, it should be trivial to rewrite it to become compatible.