Joshua Brindle wrote: > > The big problem is that the security value on system tables controls the > > _object_ represented by the row, while on user tables the security value > > represents access to the row. That is just an odd design, and why a > > regular system table security value makes sense, independent of the > > row-level security feature. > > > > I may not be understanding this but I don't see why. In SELinux everything is > an > object, and all objects have contexts. No access is specified on the object > or > in the context, that is all done in the policy currently loaded in the > security > server. system tables and user tables shouldn't be treated differently > implementation wise, they should just have a context and defer the decision > making to the policy. > > In practice the system tables (and rows within the tables) would have a > context > that restricts access tightly, but this is up to the policy, not the > implementation. > > > FYI, it is possible we might implement row-level security a different > > way in 8.5.
Seeing a pg_attribute row and seeing the column referenced by the row are not the same thing. Also, we are discussing system catalog values, (table, column, function), etc, so I don't see an performance issue. I haven't heard of anyone complaining about our ACL parsing overhead recently. A cache could still be used, but on the text string, not the oid. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
