Re: support for CREATE MODULE

st 16. 2. 2022 v 14:17 odesílatel Jim Mlodgenski <jimmy76(at)gmail(dot)com> napsal:

>
>
> On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
>
>
The proposal doesn't help with isolation PL/pgSQL code from outside. This
is just secondary collecting, and I agree with other people that say so
maybe extending extensions can be good enough for this case.

Regards

Pavel