Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I don't think it's a bug, I think it's an intentional design tradeoff. > >> To suppress an update in this case, the trigger would have to grovel > >> through the individual fields and detoast them before comparing. > >> That would add a lot of cycles, and only seldom add successes. > >> > >> Possibly we should adjust the documentation so that it doesn't imply > >> that this trigger guarantees to suppress every no-op update. > > > That doesn't sound like a very plausible argument to me. I don't > > think that a proposal to add a function named > > sometimes_suppress_redundant_updates_trigger() would've attracted many > > votes. > > You'd be wrong. The entire point of this trigger is to save cycles, > so having it eat a lot of cycles only to fail is not an improvement.
I suppose that either behavior may be desirable depending on circumstances. Maybe it is possible to have each installed trigger be configurable so that it can select either behavior. (Maybe use the trigger argument as a column list, and for each column in the list, do a full detoast and compare instead of relying on toast pointer equality). The current behavior seems more convenient in more cases, and so should remain the default. But this sounds like an additional feature, not a bug. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers