On Sat, Sep 6, 2014 at 7:51 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 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.
+1 -- this would mean my original proposal would be possible, i.e. no syntax change at all. But to solve this the proper way, and avoid a long list of options/settings, it would be really nice being able to define a new language, like "pltrustly", which sets the mix of settings which are relevant for us, where this would be a setting which is apparently not desirable for everybody. I also hope all the other things listed in the wiki* are possible to fix in PL/pgSQL 2 (or even better in PL/pgSQL, if possible). Pavel, do you have any input on the other items on the wiki? Most of them are problems which really ought to raise errors. *) https://wiki.postgresql.org/wiki/Improving_PL/PgSQL_(September_2014) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers