Re: Triggers with DO functionality

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

In response to

Responses

Browse pgsql-hackers by date

  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