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.
