On Thu, Nov 28, 2019 at 8:25 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Nov 27, 2019 at 8:35 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > A bit of investigation showed that this is caused by commit
> > ff11e7f4b9ae017585c3ba146db7ba39c31f209a. I haven't yet looked at the
> > commit in any detail, though.
>
> I spent some time studying the commit.
Another minor thing I noticed about the commit is this:
@@ -4281,31 +4266,38 @@ AfterTriggerExecute(AfterTriggerEvent event,
* that is stored as a heap tuple, constructed in different memory
* context, in the slot anyway.
*/
- LocTriggerData.tg_trigtuple =
ExecFetchSlotHeapTuple(trig_tuple_slot1,
- true, NULL);
- LocTriggerData.tg_trigtuplebuf = InvalidBuffer;
+ LocTriggerData.tg_trigslot = trig_tuple_slot1;
+ LocTriggerData.tg_trigtuple =
+ ExecFetchSlotHeapTuple(trig_tuple_slot1, true,
&should_free_trig);
+ LocTriggerData.tg_newslot = trig_tuple_slot2;
LocTriggerData.tg_newtuple =
((evtshared->ats_event & TRIGGER_EVENT_OPMASK) ==
TRIGGER_EVENT_UPDATE) ?
- ExecFetchSlotHeapTuple(trig_tuple_slot2, true, NULL) : NULL;
- LocTriggerData.tg_newtuplebuf = InvalidBuffer;
+ ExecFetchSlotHeapTuple(trig_tuple_slot2, true,
&should_free_new) : NULL;
break;
LocTriggerData.tg_newslot is always set to trig_tuple_slot2, but I
think we should set it to trig_tuple_slot2 if UPDATE, NULL otherwise,
to ensure that it's a NULL pointer if INSERT/DELETE, which I think
trigger-function authors would assume. So I updated the patch.
Attached is an updated version of the patch.
Other changes:
* The commit forgot to update the documentation on the trigger
interface, so I updated it (as such).
* I added a bit more regression test cases.
Best regards,
Etsuro Fujita
