plpgsql defensive mode

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема plpgsql defensive mode
Дата
Msg-id CAFj8pRCibCm1MGxHWdrxkwinbm=aFshRmv2LW5xqaA1qhSOjpA@mail.gmail.com
обсуждение исходный текст
Ответы Re: plpgsql defensive mode
Re: plpgsql defensive mode
Список 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

В списке pgsql-hackers по дате отправления: