Hi
There was a long discussion about future of PLpgSQL.
I accept so Joel, Marko has good ideas based on probably strong experience from their domain. I can't accept their implementation and proposals as default for PLpgSQL now and in future. They try to mix wine and vodka concepts, and it has no good ends.
I understand to their proposal as restrictive subset of PLpgSQL. "restrictive subset" is not good name. We can implement some features without impact on syntax as block on function level. Marko likes defensive programming, so we can use a name "defensive_mode"
In this mode .. all DML statements should to return EXACTLY ONE row with exception CURSORs and FOR LOOP cycle where more rows is expected. But in this case we can raise a exception NODATA if there is no row.
In this mode late IO casting will be disabled. We can disallow implicit casting too.
We can talk what plpgsql warnings in this mode will be critical.
This mode can be enabled for function by option
#option defensive
or for all plpgsql functions by GUC
SET plpgsql.defensive = on
In this moment I don't see a necessity to change or enhance syntax.
I have no plan to use it as default, but anybody can do it simply by change one GUC in Postgres configuration. Defensive mode (strict defensive mode) is good strategy, but it is not for all.
Regards
Pavel