From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Minor BEFORE DELETE trigger fix |
Date: | 2004-08-07 06:32:34 |
Message-ID: | Pine.LNX.4.58.0408071625280.3171@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Sat, 7 Aug 2004, Tom Lane wrote:
> Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > Attached in the usual format this time.
>
> AFAICS this patch makes exactly zero change in behavior. What was
> the point again?
With BEFORE DELETE triggers, if the trigger returns NULL, then the DELETE
will not take place. The following is the existing code:
for (i = 0; i < ntrigs; i++)
{
Trigger *trigger = &trigdesc->triggers[tgindx[i]];
if (!trigger->tgenabled)
continue;
LocTriggerData.tg_trigtuple = trigtuple;
LocTriggerData.tg_trigger = trigger;
newtuple = ExecCallTriggerFunc(&LocTriggerData,
relinfo->ri_TrigFunctions + tgindx[i],
GetPerTupleMemoryContext(estate));
if (newtuple == NULL)
break;
if (newtuple != trigtuple)
heap_freetuple(newtuple);
}
heap_freetuple(trigtuple);
return (newtuple == NULL) ? false : true;
Now, if for all the triggers on the base relation, !trigger->tgenabled is
true, then newtuple will always be NULL.
At the moment, this situation shouldn't come up. But it will when we
support DISABLE trigger. Arul, from Fujitsu, is planning to implement that
for 8.1 so I thought I'd ease the way.
>
> Also, if there is a point, why are we changing only one of the
> several ExecFOOTriggers functions?
Because only BEFORE DELETE worries about trigger procedures returning
NULL, from memory.
Thanks,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-07 06:49:06 | Re: UNICODE characters above 0x10000 |
Previous Message | John Hansen | 2004-08-07 06:29:20 | Re: UNICODE characters above 0x10000 |