Hi, On Thu, Feb 03, 2022 at 10:42:32PM -0300, Alvaro Herrera wrote: > 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
Ah, sorry I missed this one. > 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? This approach seems way better as it indeed fixes the qualification issues with the patch proposed in this thread.
