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