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