Re: [v9.2] Fix Leaky View Problem

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.

> 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?

nm

[1] http://archives.postgresql.org/message-id/AANLkTil1n2qWDD7IZlgBVt2IFL29rWfVkSseL9b9r2Fi@mail.gmail.com