Tom Lane wrote: > The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time.
Is the "never" is really correct? In the following case, it is necessary not to apply optimization: - SE-PostgreSQL is working, and its row-level access controls are available (sepostgresql_row_level=on). - Row-level ACL is available on the target relation. It is controlable via table option. So, it is necessary to add a new security hook to give a hint the optimizer. Sorry, I overlooked this optimization. But is is not a fundamental design issue. PGACE already has a hook to give a hint to optimizer. It will be a similar one. See, pgaceAllowFunctionInlined(...); http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/pgaceHooks.c#948 Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
