2011/10/8 Noah Misch <n...@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 . 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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers