Yes, anything a user may want to do with modules is likely possible to
do already with schemas. But just because it is possible doesn't mean
it is not tedious and awkward because of the mechanisms available to do
them now. And I would advocate for more expressive constructs to enable
users of PostgreSQL to focus and reason about more of the "what" than
the "how" of the systems they are trying to build or migrate.
Nobody will talk against better modularization. But it is not coming with your proposal.
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.
