Thread: tg_trigtuple not NULL in AFTER STATEMENT triggers?

I've noticed that tg_trigtuple and tg_newtuple aren't cleared to
NULL in AFTER STATEMENT triggers.  Is that an oversight, or does
the code intentionally not bother because trigger functions shouldn't
be referencing those members in statement-level triggers anyway, or
is there some other reason?

-- 
Michael Fuhr

Michael Fuhr <mike@fuhr.org> writes:
> I've noticed that tg_trigtuple and tg_newtuple aren't cleared to
> NULL in AFTER STATEMENT triggers.  Is that an oversight,

Probably.  Send a patch?
        regards, tom lane

On Mon, Jul 31, 2006 at 11:12:14AM -0400, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > I've noticed that tg_trigtuple and tg_newtuple aren't cleared to
> > NULL in AFTER STATEMENT triggers.  Is that an oversight,
> 
> Probably.  Send a patch?

Sure.  Is the switch in AfterTriggerExecute() around line 2116 in
commands/trigger.c close to where I should be looking?

-- 
Michael Fuhr

Michael Fuhr <mike@fuhr.org> writes:
> On Mon, Jul 31, 2006 at 11:12:14AM -0400, Tom Lane wrote:
>> Michael Fuhr <mike@fuhr.org> writes:
>>> I've noticed that tg_trigtuple and tg_newtuple aren't cleared to
>>> NULL in AFTER STATEMENT triggers.  Is that an oversight,
>> 
>> Probably.  Send a patch?

> Sure.  Is the switch in AfterTriggerExecute() around line 2116 in
> commands/trigger.c close to where I should be looking?

Yeah, it looks like some attention needs to be paid to whether
ate_oldctid and ate_newctid were supplied, rather than just blindly
passing pointers to possibly-uninitialized local structs.

Offhand I think you could remove the "switch" entirely in favor of
driving the setup of these fields off the "if (ItemPointerIsValid(..."
tests.
        regards, tom lane