Re: BUG #16613: Built in suppress_redundant_updates_trigger() trigger not supressing redundant updates

Hi Tom,

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(at)sss(dot)pgh(dot)pa(dot)us> a écrit :

> PG Bug reporting form <noreply(at)postgresql(dot)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
>

--
Stéphane Desnault