On Sat, 7 Aug 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
