'I've mentioned several times that sort_key hierarchies could be moved into a separate table, and used as a mapping table. One advantage would be that you could create more than one security context for an object (or more than one of any type of hierarchy). This would allow you to add a "parent" object for all news items and use that item for permissions, while the package object would be on the same level, but not related to the "news admin" security object.'
I have yet to see a specific example where this level of extra complexity is needed. I do plan (someday, eventually) to move context_id out of acs_objects since it's only used as something to hang triggers onto (all the real work is done in a hierarchy table), but that's more for efficiency than anything else.
Among other things we don't *use* sortkeys for tree hierarchies in Oracle, and I'd like to avoid it. In fact, if PG's hierarchical queries are efficient (I think they may appear in 7.5, implemented in SQL standard fashion) I would suggest that eventually we may switch PG to use them, though we'd want timing experiments first of course (sortkeys are one reason why object creation is slower in PG than in Oracle, a good reason to be very cautious in suggesting we switch to sortkeys in Oracle so we can maintain a forest rather than a tree).
On the other hand, the context hierarchy table doesn't use sortkeys, but rather parent/child relationships, in both PG and Oracle, so once we fully separate the permission hierarchy from the physical object tree hierarchy modelling multiple hierarchies for the context structure would be possible, even if (IMO) undesirable.
As I mentioned above, the problem Dave's brought up
could be solved by having a news-admin group with admin privs on the "news_item" object type proxy object (something we should have for this and other reasons, I think). Aplications are free to pull other tricks such as use the package object as a proxy object for specialized permission checking if necessary.
