Re: 8.4 release planning

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 <kaigai@ak.jp.nec.com>