Thanks for the prompt and detailed answer. I think it needs to be explained in the documentation. Many typical auditing setups - including some in the official documentation - add new columns to tables at the same time they add triggers. So the issue is not as obscure as it may look. I solved my issue by testing for "NEW IS NOT DISTINCT FROM OLD" in my own plpgSQL trigger.
Best regards,
Stephane
Le mer. 9 sept. 2020 à 19:38, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
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.
