Re: Minor BEFORE DELETE trigger fix - Mailing list pgsql-patches

On Sat, 7 Aug 2004, Tom Lane wrote:

> Gavin Sherry <swm@linuxworld.com.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