From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Thom Brown <thom(at)linux(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Triggers with DO functionality |
Date: | 2012-02-24 19:27:36 |
Message-ID: | 24412.1330111656@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-02-24 19:40:31 | Re: Triggers with DO functionality |
Previous Message | Peter Eisentraut | 2012-02-24 19:27:24 | Re: Fix PL/Python metadata when there is no result |