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

Re: Trigger execution role (was: Triggers with DO functionality)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Browne <cbbrowne(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Trigger execution role (was: Triggers with DO functionality)
Date: 2012-02-27 23:49:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-27 23:54:41
Subject: Re: Command Triggers
Previous:From: Andres FreundDate: 2012-02-27 23:44:18
Subject: Re: Command Triggers

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