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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to