But what does the hierarchy of privileges really get us?
In *my* opinion (not shared by everyone, obviously) the hierarchy should only be used to lump privileges, the "one implies many" case.
The implementation - assign every permission in the system to the magic "0" object - is grotty but let's separate out implementation from the design semantics for a bit. If we think more about how we want the semantics to work a better implementation may fall out of it.
The current semantics allow one to create permissions that the system administrator does *not* have - all you need to do is to intentionally or forgetfully not add the child relationship between your perm and the system admin. I'm working on a client site where they actually want admins for portions of the site that the sitewide admin won't have, so I think we probably do want to maintain this.
If not, though, and if we're willing to keep the "magic admin party" object, permission_p could just check for that party and return true always.
By joining with the hierarchy table you could just grant admins the parent ("admin") perm to the object rather than all the kids. But with scoping and more judicious use of permissions (i.e not creating an "object_type_read" perm for damn near every object type in the toolkit) the number of rows added per object for the admin would be cut down tremendously and doing this assignment might be better than doing the join with the hierarchy table in terms of checking performance.
