Re: Triggers with DO functionality - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Triggers with DO functionality
Date
Msg-id 24412.1330111656@sss.pgh.pa.us
Whole thread Raw
In response to Re: Triggers with DO functionality  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Triggers with DO functionality  (Peter Eisentraut <peter_e@gmx.net>)
Re: Triggers with DO functionality  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On fre, 2012-02-17 at 16:46 -0500, Tom Lane wrote:
>> But perhaps SECURITY DEFINER is a common enough need to justify
>> including in this shorthand form.

> According to the SQL standard, trigger actions run in security definer
> mode.  I would hope that we could go with that by default for inline
> trigger actions, because it's the thing that makes sense for triggers
> most of the time anyway, I think.

Uh, I'm not sure that we are talking about the same thing.  By default,
a trigger function runs as the table owner, ie it's implicitly SEC DEF
to the table owner.  Are you saying the spec expects something different
from that?

(Thinks some more...)  Actually, the point of SECURITY DEFINER on a
trigger function is to run as somebody other than the table owner,
to wit the function owner.  And with an anonymous function there
couldn't be any other owner.  So I guess there is no need for this
clause in this context.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Fix PL/Python metadata when there is no result
Next
From: Peter Eisentraut
Date:
Subject: Re: Triggers with DO functionality