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