[HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id CAFj8pRBQ3zhckkv4TW7jzOb3igfO_0_g_nn6K252Yed6+wJM4Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: [HACKERS] merging some features from plpgsql2 project
Re: [HACKERS] merging some features from plpgsql2 project
Re: [HACKERS] merging some features from plpgsql2 project
Список pgsql-hackers
Дерево обсуждения
Hi

I reread ideas described on page https://github.com/trustly/plpgsql2

Some points are well and can be benefit for PlpgSQL.

First I describe my initial position. I am strongly against introduction "new" language - plpgsql2 or new plpgsql, or any else. The trust of developers to us is important and introduction of any not compatible or different feature has to have really big reason. PostgreSQL is conservative environment, and PLpgSQL should not be a exception. More - I have not any information from my customers, colleagues about missing features in this language.  If there is some gaps, then it is in outer environment - IDE, deployment, testing,

I understand so we have to do some break compatibility changes, but the changes should be smoothly with possibility to simply identify necessary changes, but better don't do it - and use other possibility.

i lost hope so plpgsql_check can be integrated to core. It is living outside well - only preparing dll for MSWindows is annoyance. But some checks from plpgsql_check can be implemented in core as extra_checks, and some checks from plpgsql2 can be implemented in plpgsql_check.

Points from plpgsql2:
* SELECT .. INTO vs. TOO_MANY_ROWS - can be implemented as extra check
* SELECT .. INTO and the number of result columns - good extra check too

* EXECUTE and FOUND - this is incompatible change, extra check can be used (test on unset variable). I see solution in leaving FOUND variable and introduction of some new without this issue - ROW_COUNT maybe (this is another possible incompatible change, but with higher benefit - maybe we can introduce some aliasing, PRAGMA clause, default PRAGMAs, ..).

* SELECT .. INTO and := - looks bizarre, but I see clean benefit and I can accept it

* The OUT namespace and OUT parameter visibility - I don't like it - not in this form - can we introduce some form of namespace aliasing? The arguments are in function name named namespace already.

Now, we doesn't use plpgsql_extra_check much and it is pity.

I thing so real question is support some macros, that can help with code maintenance for different PostgreSQL versions. PostGIS code is nice example what we are missing.

Regards

Pavel

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