Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-02-24 19:40:31
Subject: Re: Triggers with DO functionality
Previous:From: Peter EisentrautDate: 2012-02-24 19:27:24
Subject: Re: Fix PL/Python metadata when there is no result

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group