On Sat, Sep 6, 2014 at 7:51 AM, Pavel Stehule <pavel.stehule@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)