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.
Attached is an example. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
public-schema.sql
Description: application/sql
