From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to> |
Subject: | plpgsql defensive mode |
Date: | 2014-09-06 05:51:36 |
Message-ID: | CAFj8pRCibCm1MGxHWdrxkwinbm=aFshRmv2LW5xqaA1qhSOjpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Brightwell, Adam | 2014-09-06 06:54:50 | Re: RLS Design |
Previous Message | Pavel Stehule | 2014-09-06 05:27:51 | Re: proposal: plpgsql - Assert statement |