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
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.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Reply via email to