KaiGai Kohei wrote: > Bruce Momjian wrote: > > 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. > > When the binary is built with the SQL-level row permissions and scanned > table does not activated it, all it does is checking a flag variable > at Relation->rd_options. I guess it will be acceptable cost. > > In this case, DBA disables row-level permission on the table, so > no additional security field is required. > > > 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. > > It is not a zero, but tiny as far as we can ignore it in my opinion.
Yes. It is good to have SQL-level row security available by default in every binary, even if it requires a few checks in C. -- 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
