Re: support for CREATE MODULE

From: Swaha Miller <swaha(dot)miller(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: support for CREATE MODULE
Date: 2022-02-14 23:23:07
Message-ID: CAPXknY5Qz+bRy8Htniy7bJfK7rHmtQSiuDtEVinDsvpVAuv7iQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 10, 2022 at 1:06 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Thu, Feb 10, 2022 at 08:53:15AM -0800, Swaha Miller wrote:
> > On Fri, Feb 4, 2022 at 3:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Hm. If the functional requirement is "group objects without needing
> > any out-in-the-filesystem infrastructure", then I could see defining
> > a module as being exactly like an extension except there's no such
> > infrastructure --- and hence no concept of versions, plus pg_dump
> > needs to act differently. That's probably enough semantic difference
> > to justify using a separate word, even if we can share a lot of
> > code infrastructure.
> >
> > Then as a first cut for modules, could we add CREATE MODULE
> > syntax which adds an entry to pg_extension like CREATE EXTENSION
> > does? And also add a new column to pg_extension to distinguish
> > modules from extensions.
> >
> > The three-part path name resolution for functions would remain the
> > same, nothing would need to change there because of modules.
> >
> > Would that be an acceptable direction to go?
>
> Well, that would allow us to have CREATE EXTENSION syntax, but what
> would it do that CREATE SCHEMA does not?
>

A prominent use case for grouping functions into modules would
be access control on the group as a whole, with one command
for an entire module instead of many individual functions. One reason
for such a grouping is to set ACLs. Users migrating their database from
commercial databases to PostgreSQL wanting to set ACLs on
thousands or hundreds of thousands of functions would benefit from
a grouping concept like modules.

If users use schemas to group functions, then they have to break up
functions that may have all been in one namespace into a bunch of new
schemas. So we'd like to have a different grouping mechanism that can
group functions within a schema. So we're looking at a new construct like
modules that can serve that purpose without introducing sub-schemas.

Also a module would be a grouping of primarily functions. Schemas can
have many other object types. Setting ACLs on groups of functions in a
schema, which is what users could do with a module, would require
breaking up a schema into other schemas based on ACLs. But schemas
allow setting ACLs on other objects in it, not only functions. If we
create groupings based on functions, what happens to the other types
of objects, what schema do they get grouped into? If modules are
supposed to solve setting ACLs on groups of functions, does using
schemas conflate setting ACLs for those other types of objects with
setting ACLs for functions?

Modules could also, in the future, serve as a way of allowing for private
functions within the grouping. Doing this in schemas would require
those kinds of changes in the schema construct.

Swaha

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-14 23:23:48 Re: automatically generating node support functions
Previous Message Jacob Champion 2022-02-14 23:07:38 Re: pgcrypto: Remove internal padding implementation