2011/9/26 Robert Haas <robertmh...@gmail.com>: > On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch <n...@leadboat.com> wrote: >> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote: >>> Robert Haas 09/25/11 10:58 AM >>> >>> >>> > I'm not sure we've been 100% consistent about that, since we >>> > previously made CREATE OR REPLACE LANGUAGE not replace the owner >>> > with the current user. >>> >>> I think we've been consistent in *not* changing security on an >>> object when it is replaced. >> >>> [CREATE OR REPLACE FUNCTION does not change proowner or proacl] >> >> Good point. C-O-R VIEW also preserves column default values. I believe we >> are >> consistent to the extent that everything possible to specify in each C-O-R >> statement gets replaced outright. The preserved characteristics *require* >> commands like GRANT, COMMENT and ALTER VIEW to set in the first place. >> >> The analogue I had in mind is SECURITY DEFINER, which C-O-R FUNCTION reverts >> to >> SECURITY INVOKER if it's not specified each time. That default is safe, >> though, >> while the proposed default of security_barrier=false is unsafe. > > Even though I normally take the opposite position, I still like the > idea of dedicated syntax for this feature. Not knowing what view > options we might end up with in the future, I hate having to decide on > what the general behavior ought to be. But it would be easy to decide > that CREATE SECURITY VIEW followed by CREATE OR REPLACE VIEW leaves > the security flag set; it would be consistent with what we're doing > with owner and acl information and wouldn't back us into any > unpleasant decisions down the road. > Does the CREATE SECURITY VIEW statement mean a synonym of CREATE VIEW ... WITH (security_barrier=true) ?
If so, it seems to me reasonable to keep the configuration when user provides no explicit option. 1) an explicit WITH(security_barrier=true) / CREATE SECURITY VIEW -> It always turns on a security_barrier option. 2) an explicit WITH(security_barrier=false) -> It always turns off security_barrier option. 3) no explicit option / CREATE VIEW -> Keep existing configuration, although inconsist with SECURITY DEFINER Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
