On 2021-Jun-02, Jim Mlodgenski wrote: > Attached is a POC patch for modules. I modeled it as a sub-schema because > that is more what it seems like to me. It adds additional columns to > pg_namespace and allows for 3-part (or 4 with the database name) naming > of objects within the module. This simple example works with the patch.
Given the downthread discussion, this idea doesn't seem workable. People are now discussing "what if the module is some kind of extension". But to me that seems to go against the grain; you'd have to implement a ton of stuff in order to let "extension-modules" be installed without on-disk foo.control files. But what if the module is just a particular kind of *namespace*? I mean, what if CREATE MODULE is implemented by creating a row in pg_namespace with nspkind='m'? So a pg_namespace row can refer to either a regular schema (nspkind='s') or a module. In a schema you can create objects of any kind just like today, but in a module you're restricted to having only functions (and maybe also operators? other types of objects?). Then, a qualified object name foo.bar() can refer to either the routine bar() in schema foo, or routine bar in module foo. To the low-level code it's pretty much the same thing (look the namespace in pg_namespace just as today). What other properties do you want modules to have? Are there "private" functions? (What *is* a private function in this context? I mean, how does "being in a module" interact with object lookup rules? Does plpgsql have to be aware that a routine is in a module?) Are there module-scoped variables? (If so, you probably want Pavel Stehule's variable patch pushed ahead of time). -- Álvaro Herrera 39°49'30"S 73°17'W
