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.
