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.



> Cheers
> Serge Rielau
> Salesforce.com <http://salesforce.com>

Reply via email to