2011/9/26 Robert Haas <robertmh...@gmail.com>: > On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> 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 > > No, you're missing my point completely. If we use a flexible options > syntax here, then we have to decide on what behavior CREATE OR REPLACE > should have for all future options, without knowing what they are yet, > or what behavior will be appropriate. > Hmm. Indeed, it seems to me fair enough reason.
In this syntax case, the only way to clear the security_barrier flag is to drop view once, then create a view, isn't it? And, is the security_barrier flag still stored within reloptions field? 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