Hi,
It looks like you know what is happening, but I found that I have made an error in my original assumption: (while the steps to reproduce are still valid)
The size of the string at which the trigger does not work as expected varies, depending on the size of the other fields in the row.
The 'limit size' is lower if I set bigger values in another text field in the same row (and it seems that it is reached when going above 2000 octet for the texts cells added up).
Sorry if this is noise, and thank you for looking into the bug (or documentation error).
Regards,
Artus de Benque
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane <tgl@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.
regards, tom lane