On Thu, 2009-09-03 at 10:24 -0400, Robert Haas wrote: > If TRIGGER ON UPDATE OF foo_id means whether the value actually > changed, then I can skip the check. If TRIGGER ON UPDATE OF foo_id > means whether the column was present in the update list, then it > doesn't. Perhaps there are some use cases where we can be certain > that we only care about whether the value was in the update list, and > not whether it was changed, but off the top of my head it seems like > 0% of mine would fall into that category.
Yeah, probably. I didn't make this up; I'm just reading the standard. ;-) But of course you can already do what you do, so you don't lose anything if it turns out that this proposed feature ends up working the other way. > It also seems to me logically inconsistent that we would expose this > information via the CREATE TRIGGER interface but not to the trigger > function itself. From within the function, you can compare NEW and > OLD, but you get no visibility into which columns were actually > updated. And apparently now from within CREATE TRIGGER we'll have > just the opposite. Blech... Well, it might make sense to make this information available within the trigger function through new variables. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
