PG Bug reporting form <noreply@postgresql.org> writes:
> The built-in suppress_redundant_updates_trigger() trigger is not supressing
> redundant updates after an ALTER TABLE ... ADD COLUMN...
This doesn't seem like a bug. The trigger code is looking for bitwise
equality between new tuple and old tuple, which it won't find because
the new tuple will have a larger number-of-attributes field; not to
mention a possibly-wider nulls bitmap.
Sure, we could complicate the trigger to try to understand such cases,
but that would likely make things net slower in most applications.
The hard part of having such a trigger is that it's pure overhead
for real updates, so that overhead has to be minimized.
Possibly the documentation could be clarified. What it says now is
"prevent any update that does not actually change the data in the
row from taking place", which is pretty vague about what the criteria
really are. Not sure about better wording though.
regards, tom lane
