| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Michael Fuhr <mike(at)fuhr(dot)org> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: tg_trigtuple not NULL in AFTER STATEMENT triggers? | 
| Date: | 2006-07-31 17:06:04 | 
| Message-ID: | 25642.1154365564@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Mon, Jul 31, 2006 at 11:12:14AM -0400, Tom Lane wrote:
>> Michael Fuhr <mike(at)fuhr(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2006-07-31 17:50:23 | Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results) | 
| Previous Message | Chris Browne | 2006-07-31 16:45:58 | Re: Connection limit and Superuser |