2017-01-13 18:35 GMT+01:00 Serge Rielau <se...@rielau.com>: > >> * A design that can fit in with PostgreSQL >> * Solid benefits beyond "makes life easier for Oracle users" to >> justify each feature/change >> * Funding/time to make it happen >> >> So far, I haven't seen anyone with one of those, let alone all three. >> > OK, I’ll bite… > > * In SFDC’s extension of PostgreSQL we nest namespaces. > This was done before my time here, but its very stable. It's easy to > keep merged and not that much code. > To make the special semantics of these nested namespaces evident however > we leaned on the SQL/PSM standard and call them MODULE’s. > Unlike the standard our MODULEs share the namespace (no pun intended) > with regular schemata which seems practical and limits confusion when > referencing > a module without schema qualification. > > We did extend upon the standard with ALTER MODULE .. ADD [FUNCTION | > TYPE | …] syntax. > Just like few users create a new schema with tables in one statement, > no-one actually creates a module with content in one statement (unless, as > in Oracle they have to). > This was done before my time as well, but parallels what we implemented > did in DB2 for the reasons described earlier in this thread. > You want to be able to modify members of a module separately. > > Starting with a blank slate I do wonder whether simply allowing nesting > of namespaces would be sufficient to achieve the vast majority of the goal. > I.e. CREATE SCHEMA <schema>.<newschema> > The rest… follows trivially :-) > > * Benefits: > a) The files on my computer are organized in directories that have more > than one level of nesting. > I simply can’t imagine having thousands or tens of thousands of > objects lying around and only one coarse way of subdividing them. > This is compounded by the desire you version. I want to the same > names for objects across multiple concurrently present versions of the > schema. > If I consume the schema for the version the entire schema for a > version becomes a flat jumple. > b) Access control > By putting things that belong together actually together in an > explicit way I can achieve scoping without having to resort to permissions. > I can simply postulate that all objects in a module are private > unless they are published. > Access control happens at the module level. > This is no different than library management on your OS. > You don’t chmod the individual entry points! > c) Scoping > Similar to the above, but more related to search path. > Within a module I can be assured that any unqualified references will > first resolve within the module. > No mucking with the search path by anyone will cause me to execute > the wrong function, resolve to the wrong type etc. > > Simply put: As long as we agree that users want to implement substantial > server side logic the conclusion that standard programming > abstractions such as classes and member functions are a boon seems to be > obvious. > > Note that I have been careful not to tie modules too strongly to > specific types. Conceptually I see nothing from with a module, table, view, > etc. > It’s just a bit more “far out” since there is AFAIK no precedence. > > * IFF our existing efforts (fast defaults and executor runtime > improvements) to work with the community are successful I would happily > lobby > to at least port our module code to the community codebase. We can take > it from there. >
I have not clean feeling from this - I am pretty sure so I am afraid schizophrenic between MODULES, SCHEMAS. Nested schemas increase complexity of searching complexity and breaks a logic database.schema.object. Currently almost all in PostgreSQL PL design is primitive, but that means pretty simple too. It is hard to see a advantages of this proposal. Regards Pavel > Cheers > Serge Rielau > Salesforce.com <http://salesforce.com> > > > >
