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.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
