I think it's much better to make it the default behaviour in plpgsql2 than to add a new syntax to plpgsql, because then we don't have to argue what to call the keyword or where to put it.
Then you'll have to argue what the *other* syntax should look like. And not everyone agrees on the default either, see Kevin's email. Designing a new language is going to be an uphill battle, even more so than enhancing current plpgsql.
Any ideas on what the *other* syntax could look like?
When I've played around with the idea of fixing PL/PgSQL in my head, what I had in mind is that UPDATE and DELETE not affecting exactly one row raises an exception, unless PERFORM is used. PERFORM would set a special variable (e.g. ROW_COUNT) which can be consulted after the operation.
For example:
UPDATE foo WHERE bar = 1; -- must affect exactly one row PERFORM UPDATE foo WHERE bar = 1; -- can affect any number of rows IF row_count > 1 THEN RAISE EXCEPTION 'oh no'; END IF;
This, obviously, requires us to get rid of the requirement for PERFORM today, which I see as a win as well.
This example is inspiration for me.
one row result can be enforced by some function option.
PERFORM update we don't need, because this code can be moved to other function where one row result will not be enforced.
If I understand to Joel's motivation, he don't need to mix both styles in one function.
one row result can be enforced by function option, function setting or by GUC.