> Kevin Grittner wrote:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> By default, a trigger function runs as the table owner, ie it's
>>> implicitly SEC DEF to the table owner.
>>
>> Really? That's certainly what I would *want*, but it's not what
>> I've seen.
>>
>> [self-contained example of that not happening]
Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
>
> Yeah, not quite consistent with what I've seen.
Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> Yes, you're right
As far as I can tell, triggers run as the user performing the
operation which fires the trigger, not as the owner of the table.
Can anyone provide an example of a trigger running as the table
owner? Is there a bug here? Something for the docs?
Test case (slightly modified) in runnable format, rather than a
copy/paste of a run:
create user bob;
create user ted;
--
set role bob;
create table t (id int not null primary key, val text);
create table s (id int not null primary key, val text not null);
grant select, insert, update, delete on t to ted;
grant select on s to ted;
create function t_ins_func() returns trigger language plpgsql as
$$
begin
raise notice 'role = ''%''', current_user;
if new.val is not null then
insert into s (id, val) values (new.id, new.val);
end if;
return new;
end;
$$;
create trigger t_ins_trig before insert on t
for each row execute procedure t_ins_func();
--
reset role; set role ted;
insert into t values (1, null);
select * from s;
select * from t;
insert into t values (2, 'two');
-Kevin