On 2022-Feb-03, Pavel Stehule wrote:
> The biggest problem is coexistence of Postgres's SEARCH_PATH object
> identification, and local and public scopes used in MODULEs or in Oracle's
> packages.
>
> I can imagine MODULES as third level of database unit object grouping with
> following functionality
>
> 1. It should support all database objects like schemas
I proposed a way for modules to coexist with schemas that got no reply,
https://postgr.es/m/202106021908.ddmebx7qfdld@alvherre.pgsql
I still think that that idea is valuable; it would let us create
"private" routines, for example, which are good for encapsulation.
But the way it interacts with schemas means we don't end up with a total
mess in the namespace resolution rules. I argued that modules would
only have functions, and maybe a few other useful object types, but not
*all* object types, because we don't need all object types to become
private. For example, I don't think I would like to have data types or
casts to be private, so they can only be in a schema and they cannot be
in a module.
Of course, that idea of modules would also ease porting large DB-based
applications from other database systems.
What do others think?
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
