Re: [PATCHES] tg_trigtuple/tg_newtuple settings in AFTER triggers
Michael Fuhr <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] tg_trigtuple/tg_newtuple settings in AFTER triggers
On Thu, Aug 03, 2006 at 12:05:23PM -0400, Tom Lane wrote: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether > > old and new tuples were supplied rather than blindly setting them > > according to the event type. Per discussion in pgsql-hackers. > > Looks good, applied. 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. -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] tg_trigtuple/tg_newtuple settings in AFTER triggers
Michael Fuhr <[EMAIL PROTECTED]> writes: > Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether > old and new tuples were supplied rather than blindly setting them > according to the event type. Per discussion in pgsql-hackers. Looks good, applied. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
