Re: Support for CREATE MODULE?

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Jim Mlodgenski <jimmy76(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support for CREATE MODULE?
Date: 2021-06-02 19:08:44
Message-ID: 202106021908.ddmebx7qfdld@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-06-02 19:20:11 Re: security_definer_search_path GUC
Previous Message Tom Lane 2021-06-02 18:39:20 Re: parent foreign tables and row marks