On Mon, Feb 14, 2022 at 4:58 PM Bruce Momjian <br...@momjian.us> wrote:
> 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. > 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 for a talk. A practical scenario would require many schemas following this pattern of X and X_private. In a more expressive programming language, the user would express modular design with classes X1, X2...Xn that have both public interface calls and private functions. The modularity would reflect what they are trying to do and not be restricted by how they are allowed to do so. In this context, I am going to link to a scenario Jim had described before https://www.postgresql.org/message-id/CAB_5SRebSCjO12%3DnLsaLCBw2vnkiNH7jcNchirPc0yQ2KmiknQ%40mail.gmail.com In your example, the only way a developer would know that X and X_private are related is that they are named consistently. With another grouping construct like Modules, they would both have been in the same schema, but now they are not. From a long term maintainability of the code perspective, that becomes an issue because people make simple mistakes. What if in the future a new developer added a 3rd grouping, x_utils. Is it related to the other groupings? This has a lower case x instead of the X. How is one to know? What if in the future a new developer added a 3rd grouping X_utils but without having paid attention to the already existing X and X_private? Now naming becomes the means of expressing classification and modular design. It is a relatively weak construct compared to a language construct. 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. Swaha
