From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jim Mlodgenski <jimmy76@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Support for CREATE MODULE?
In-reply-to: 
 <CAB_5SRebSCjO12=nLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ@mail.gmail.com>
References: 
 <CAB_5SRebSCjO12=nLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ@mail.gmail.com>
Comments: In-reply-to Jim Mlodgenski <jimmy76@gmail.com>
	message dated "Wed, 02 Jun 2021 09:38:39 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2897115.1622642280.1@sss.pgh.pa.us>
Date: Wed, 02 Jun 2021 09:58:00 -0400
Message-ID: <2897116.1622642280@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2897116.1622642280%40sss.pgh.pa.us>
Precedence: bulk

Jim Mlodgenski <jimmy76@gmail.com> writes:
> Questions
> - Do we want to add module support?

Certainly many people have asked for that, or things like that.

> - If we do, should it be implemented as a type of namespace or should it
>   be its own object type that lives in something like pg_module?

While I didn't read the actual patch, your sketch just above this makes
me want to run away screaming.  In the first place, what do you think
the primary key of pg_namespace is now?  But the bigger problem is that
sub-namespaces just do not work in SQL syntax.  Back when we first added
schema support, I had some ambitions towards allowing nested schemas,
which is a big part of the reason why pg_namespace is named that and not
pg_schema.  But the idea fell apart after I understood the syntactic
ambiguities it'd introduce.  It's already quite hard to tell which part
of a multiply.qualified.name is which, given that SQL says that you can
optionally put a "catalog" (database) name in front of the others.
I really doubt there is a way to shoehorn sub-schemas in there without
creating terrible ambiguities.  Is "a.b.c" a reference to object c in
schema b in database a, or is it a reference to object c in sub-schema b
in schema a?  This is why we've ended up with bastard syntax like
(table.column).subcolumn.

> - How should users interact with objects within a module? They could be
>   mostly independent like the current POC or we can introduce a path like
>   ALTER MODULE foo ADD FUNCTION blah

I wonder whether it'd be better to consider modules as a kind of
extension, or at least things with the same sort of ownership relations
as extensions have.

			regards, tom lane