Re: support for CREATE MODULE - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: support for CREATE MODULE
Date
Msg-id Yg6b2y1ynckX/uo9@momjian.us
Whole thread Raw
In response to Re: support for CREATE MODULE  (Swaha Miller <swaha.miller@gmail.com>)
Responses Re: support for CREATE MODULE
List 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@momjian.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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Isn't gist_page_items broken for opclasses with compress methods?
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Support pg_ident mapping for LDAP