On Thu, Feb 10, 2022 at 1:06 PM Bruce Momjian <br...@momjian.us> wrote:
> On Thu, Feb 10, 2022 at 08:53:15AM -0800, Swaha Miller wrote: > > On Fri, Feb 4, 2022 at 3:51 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Hm. If the functional requirement is "group objects without needing > > any out-in-the-filesystem infrastructure", then I could see defining > > a module as being exactly like an extension except there's no such > > infrastructure --- and hence no concept of versions, plus pg_dump > > needs to act differently. That's probably enough semantic difference > > to justify using a separate word, even if we can share a lot of > > code infrastructure. > > > > Then as a first cut for modules, could we add CREATE MODULE > > syntax which adds an entry to pg_extension like CREATE EXTENSION > > does? And also add a new column to pg_extension to distinguish > > modules from extensions. > > > > The three-part path name resolution for functions would remain the > > same, nothing would need to change there because of modules. > > > > Would that be an acceptable direction to go? > > Well, that would allow us to have CREATE EXTENSION syntax, but what > would it do that CREATE SCHEMA does not? > 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. Also a module would be a grouping of primarily functions. Schemas can have many other object types. Setting ACLs on groups of functions in a schema, which is what users could do with a module, would require breaking up a schema into other schemas based on ACLs. But schemas allow setting ACLs on other objects in it, not only functions. If we create groupings based on functions, what happens to the other types of objects, what schema do they get grouped into? If modules are supposed to solve setting ACLs on groups of functions, does using schemas conflate setting ACLs for those other types of objects with setting ACLs for functions? Modules could also, in the future, serve as a way of allowing for private functions within the grouping. Doing this in schemas would require those kinds of changes in the schema construct. Swaha
