plpgsql defensive mode

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

Responses

Browse pgsql-hackers by date

  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