From: | Stephane Desnault <stephane(dot)desnault(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16613: Built in suppress_redundant_updates_trigger() trigger not supressing redundant updates |
Date: | 2020-09-09 18:05:11 |
Message-ID: | CALo1QFhuBmqao5ZENK4bFZLx3PiWOnRY3hXjgEP7cbvO0JNV-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-09-09 18:47:36 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
Previous Message | Tom Lane | 2020-09-09 17:38:50 | Re: BUG #16613: Built in suppress_redundant_updates_trigger() trigger not supressing redundant updates |