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