KaiGai Kohei wrote: > > What I am saying is for the default compile, SQL-level ACLs should be > > possible because, since the ACL field has optional storage, there is no > > downside to have it be available by default. > > I think it is a possible and desirable desicion from the viewpoint of > security folks. > > However, I think we have a few issues, and it makes unclear whether > we can make an agreement in the community. > The one is a cost of security hooks. They consume a bit more CPU steps > when a security mechanism is enabled. The other is prevention to override > a few hooks (ExecutorRun_hook and planner_hook), because they assume > standard implementations to be executed. > > Which is more desirable option in the default?
Well, my assumption is that if a table doesn't have SQL-level row permissions then there is no overhead becaues there are no permissions to check. If it does have SQL-level row permissions then the user who created the table has accepted the performance impact of SQL-level row permissions. I would think it would be pretty easy to see quickly if any table in a query has SQL-level row permissions and then take the performance hit. For example, I might want to put SQL-level row permissions on an audit table, but none of my other tables, and in that case I assume there is only a performance impact on queries that use the audit table. -- Bruce Momjian <[EMAIL PROTECTED]> 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
