2011/10/8 Noah Misch <noah@leadboat.com>:
> On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
>> My preference is still also WITH(security_barrier=...) syntax.
>>
>> The arguable point was the behavior when a view is replaced without
>> explicit WITH clause;
>> whether we should consider it was specified a default value, or we
>> should consider it means
>> the option is preserved.
>> If we stand on the viewpoint that object's attribute related to
>> security (such as ownership,
>> acl, label, ...) should be preserved, the security barrier also shall
>> be preserved.
>> On the other hand, we can never know what options will be added in the
>> future, right now.
>> Thus, we may need to sort out options related to security and not at
>> DefineVirtualRelation().
>>
>> However, do we need to limit type of the options to be preserved to
>> security related?
>> It is the first case that object with arbitrary options can be replaced.
>> It seems to me we have no matter, even if we determine object's
>> options are preserved
>> unless an explicit new value is provided.
>
> Currently, you can predict how CREATE OR REPLACE affects a given object
> characteristic with a simple rule: if the CREATE OR REPLACE statement can
> specify a characteristic, we don't preserve its existing value. Otherwise, we
> do preserve it. Let's not depart from that rule.
>
> Applying that rule to the proposed syntax, it shall not preserve the existing
> security_barrier value. I think that is acceptable. If it's not acceptable, we
> need a different syntax -- perhaps CREATE SECURITY VIEW.
>
No. It also preserves the security-barrier flag, when we replace a view without
SECURITY option. The only difference is that we have no way to turn off
security-barrier flag explicitly, right now.
The major reason why I prefer reloptions rather than "SECURITY" option is
that allows to reuse the existing capability to store a property of relation.
It seems to me both of syntax enables to achieve the rule to preserve flags
when a view is replaced.
>> Any other ideas?
>
> Suppose we permitted pushdown of unsafe predicates when the user can read the
> involved columns anyway, a generalization of the idea from the first paragraph
> of [1]. Would that, along with LEAKPROOF, provide enough strategies for shoring
> up performance to justify removing unsafe views entirely?
>
The problem was that we do all the access control decision at the
executor stage,
but planner has to make a plan prior to execution. So, it was also reason why we
have tried to add LEAKPROOF flag to functions.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>