On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote: > 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.
Yes, there are no technical barriers to implementing either behavior with either syntax. However, CREATE OR REPLACE VIEW ... WITH (...) has a precedent guiding its behavior: if a CREATE OR REPLACE statement can specify a characteristic, we don't preserve its existing value. > >> 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. Yes; we'd need to invalidate relevant plans in response to anything that changes access control decisions. GRANT and ALTER ... OWNER TO already do that, but we'd need to cover pg_authid/pg_auth_members changes, SET ROLE, SET SESSION AUTHORIZATION, and probably a few other things. That might be a substantial project in its own right. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
