Re: Packages: Again

2017-01-13 18:35 GMT+01:00 Serge Rielau <serge(at)rielau(dot)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>
>
>
>
>