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/aanlktil1n2qwdd7izlgbvt2ifl29rwfvkssel9b9r...@mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
