Re: support for CREATE MODULE

Поиск
Список
Период
Сортировка
От Jim Mlodgenski
Тема Re: support for CREATE MODULE
Дата
Msg-id CAB_5SRc+Ta2O+1DG0sGMFp+LLBpuZ5Y1QB_dZ-bi=0wmeQwvQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: support for CREATE MODULE  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: support for CREATE MODULE  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers


On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:

The main issue in this case is fact, so plpgsql is fully integrated to Postgres (on second hand this integration is a big performance win). It is pretty different from PL/SQL. In Oracle you have a package, or any other similar features, because PL/SQL is an "independent" environment to the database engine. You cannot do the same with PL/pgSQL. And if you try to implement some enhancement of object hierarchy for PL/pgSQL, then you have to do it in the PostgreSQL core engine first. I'm 100% for enhancing stored procedures about full modularization, but this feature cannot be implemented step by step because you can break compatibility in any step. We need a robust solution. The solution, that helps with something, but it is not robust, it is not progress.


I'm not sure I understand your feedback. The proposed design for modules
is implemented in the engine and is orthogonal to PL/pgSQL. A module can
contain a mix of PL/pgSQL, PL/perl and PL/TCL functions if one wants
to do something like that.

Do you have any thoughts on how some sort of modularization or grouping
should be implemented? The Module route was the first thought on this
because it's the way the spec tells us we should solve this problem. We
can invent something new if we have a better way of solving this.

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

Предыдущее
От: Sofia Kopikova
Дата:
Сообщение: Re: postgres_fdw: using TABLESAMPLE to collect remote sample
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgsql: Move scanint8() to numutils.c