Re: support for CREATE MODULE

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Swaha Miller <swaha(dot)miller(at)gmail(dot)com>
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-17 19:02:51
Message-ID: Yg6b2y1ynckX/uo9@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 15, 2022 at 12:29:54PM -0800, Swaha Miller wrote:
> On Mon, Feb 14, 2022 at 4:58 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > 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

...

> 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.

Well, I think there are two downsides of having modules that do
some things like schemas, and some not:

* You now have two ways of controlling namespaces and permissions
* It is unclear how the two methods would interact

Some people might find that acceptable, but historically more people have
rejected that, partly due to user API complexity and partly due to
server code complexity.

Given what you can do with Postgres already, what is trying to be
accomplished? Having public and private objects in the same schema?
Having public objects in a schema as visible to some users and private
objects invisible to them? The visibility control is currently not
possible without using two schemas, but access control is possible.

Now, if we could throw away are current schema/permission controls and
just use one based on modules, that might be more acceptable, but it
would cause too much breakage and be non-standard, and also be less
flexible than what we already support.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-02-17 19:15:57 Re: [PATCH] Support pg_ident mapping for LDAP
Previous Message Tomas Vondra 2022-02-17 18:55:32 Isn't gist_page_items broken for opclasses with compress methods?