Greg,
In particular, one early question was whether to use wildcard patterns or schema names. People were saying wildcard patterns would be more flexible because people don't always set up their objects in different schemas. But if we had a mechanism someone wanted to use which depended on schemas they would be far more likely to choose to set up schemas for objects which belong in different security classes.
What I'm saying is that there are many users currently using schema for security classes. I personally haven't ever encountered a DBA who used role ownership of objects as a mechanism for security context. There's nothing conceptually invalid about the latter approach, but it would be hard for DBAs to grasp, and as a result less of them would use it.
Mainly that's because the concept of schema easily maps (even if inaccurately) to the concept of directories, whose permissions IT staff are used to managing. So it's more intuitive for a DBA to say "This is sensitive data so I'm going to put it in the SENSITIVE schema" than to say "this is sensitive data so I'm going to have the table belong to the SENSITIVE role".
Further, it's common practice on other DBMSes to have a "database owner" role which owns all database objects. So DBA who learn Postgres second are going to do that.
If we were going for a theoretically pure approach, we'd actually have a "security context" concept which would include a bundle of permissions and each object would belong to one.
-- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
