Re: Trigger execution role (was: Triggers with DO functionality) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Trigger execution role (was: Triggers with DO functionality)
Date
Msg-id 21830.1330386576@sss.pgh.pa.us
Whole thread Raw
In response to Re: Trigger execution role (was: Triggers with DO functionality)  (Christopher Browne <cbbrowne@gmail.com>)
Responses Re: Trigger execution role (was: Triggers with DO functionality)  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Trigger execution role (was: Triggers with DO functionality)  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Christopher Browne <cbbrowne@gmail.com> writes:
> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So, whatever the desirability of having them run as table owner,
>> we can't just up and change that.

> I'm inclined to hold to the argument that it Works Properly Now, and
> that we shouldn't break it by changing it.

I would say the same, or at least that any argument for changing it is
probably not strong enough to trump backwards compatibility.

However, Peter seems to think the other way is required by standard.
We can get away with defining whatever behavior we want for triggers
that invoke functions, since that syntax is nonstandard anyway.  But,
if you remember the original point of this thread, it was to add syntax
that is pretty nearly equivalent to the spec's.  If we're going to do
that, it had better also have semantics similar to the spec's.

So (assuming Peter has read the spec correctly) I'm coming around to the
idea that the anonymous trigger functions created by this syntax ought
to be "SECURITY DEFINER table_owner".
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Command Triggers
Next
From: Tom Lane
Date:
Subject: Re: Command Triggers