st 16. 2. 2022 v 14:17 odesÃlatel Jim Mlodgenski <jimm...@gmail.com> napsal:
> > > On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule <pavel.steh...@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. > > 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
