public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Jim Mlodgenski <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Support for CREATE MODULE?
Date: Wed, 02 Jun 2021 09:58:00 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAB_5SRebSCjO12=nLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ@mail.gmail.com>
References: <CAB_5SRebSCjO12=nLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ@mail.gmail.com>

Jim Mlodgenski <[email protected]> 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

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Support for CREATE MODULE?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox