Re: support for CREATE MODULE

On Mon, Feb 14, 2022 at 4:58 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Mon, Feb 14, 2022 at 07:42:21PM -0500, Bruce Momjian wrote:
> > On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote:
> > > 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.
> >
> > I was working on a talk about microservices today and decided to create
> > two schemas --- a public one that has USAGE permission for other services
> > with views and SECURITY DEFINER functions that referenced a private
> > schema that can only be accessed by the owning service. Is that a usage
> > pattern that requires modules since it already works with schemas and
> > just uses schema permissions to designate public/private schema
> > interfaces.
>

I think the reason for modules would be to make it a better experience for
PostgreSQL users to do what they need. Yours is a great example
for a talk. A practical scenario would require many schemas following this
pattern of X and X_private. In a more expressive programming language,
the user would express modular design with classes X1, X2...Xn that
have both public interface calls and private functions. The modularity
would
reflect what they are trying to do and not be restricted by how they are
allowed to do so. In this context, I am going to link to a scenario Jim had
described before

https://www.postgresql.org/message-id/CAB_5SRebSCjO12%3DnLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ%40mail.gmail.com

In your example, the only way a developer would know that X and
X_private are related is that they are named consistently. With another
grouping construct like Modules, they would both have been in the same
schema, but now they are not. From a long term maintainability of the code
perspective, that becomes an issue because people make simple mistakes.
What if in the future a new developer added a 3rd grouping, x_utils. Is it
related to the other groupings? This has a lower case x instead of the X.
How is one to know? What if in the future a new developer added a 3rd
grouping X_utils but without having paid attention to the already existing
X
and X_private? Now naming becomes the means of expressing
classification and modular design. It is a relatively weak construct
compared to a language construct.

Yes, anything a user may want to do with modules is likely possible to
do already with schemas. But just because it is possible doesn't mean
it is not tedious and awkward because of the mechanisms available to do
them now. And I would advocate for more expressive constructs to enable
users of PostgreSQL to focus and reason about more of the "what" than
the "how" of the systems they are trying to build or migrate.

Swaha