Re: tg_trigtuple/tg_newtuple settings in AFTER triggers

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, pgsql-patches(at)postgresql(dot)org
Subject: Re: tg_trigtuple/tg_newtuple settings in AFTER triggers
Date: 2006-08-03 21:14:36
Message-ID: 26381.1154639676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Thanks. Alvaro made the following suggestion but didn't copy the
> list -- shall I do what he suggested and submit the changes as
> another patch?

> Alvaro Herrera wrote:
>> I'd add an Assert() on the second hunk to make sure newtuple is only set
>> in UPDATE. And also a comment on top of the "if" to explain why.

Can't get excited about that. Will you also have asserts to complain
if the wrong combinations of tuples are supplied for the other cases?
Is this really likely to catch anything? It's not like this function
is called from a variety of places.

While I was applying the patch I considered changing the
if (LocTriggerData.tg_trigtuple != NULL)
to
if ((event->ate_event & TRIGGER_EVENT_OPMASK) == TRIGGER_EVENT_UPDATE)
but this didn't seem to be an improvement on the whole, as it effectively
provides two ways to get it wrong (wrong tuple args OR wrong event)
instead of only one. I think driving the setup of the tuple fields
entirely off the provided tuple args is logically cleaner.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-03 21:30:48 Re: [BUGS] Patch to allow C extension modules to initialize/finish
Previous Message Tom Lane 2006-08-03 21:06:28 Re: O_NOATIME

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-08-03 22:00:20 Re: [PATCHES] Forcing current WAL file to be archived
Previous Message Michael Fuhr 2006-08-03 21:00:19 Re: tg_trigtuple/tg_newtuple settings in AFTER triggers