Tom Lane wrote:
> Michael Glaesemann <grzm@seespotcode.net> writes:
>
>> What would be the disadvantages of always doing this, i.e., just
>> making this part of the normal update path in the backend?
>>
>
> (1) cycles wasted to no purpose in the vast majority of cases.
>
> (2) visibly inconsistent behavior for apps that pay attention
> to ctid/xmin/etc.
>
> (3) visibly inconsistent behavior for apps that have AFTER triggers.
>
> There's enough other overhead in issuing an update (network,
> parsing/planning/etc) that a sanely coded application should try
> to avoid issuing no-op updates anyway. The proposed trigger is
> just a band-aid IMHO.
>
> I think having it as an optional trigger is a reasonable compromise.
>
>
>
Right. I never proposed making this the default behaviour, for all these
good reasons.
The point about making the app try to avoid no-op updates is that this
can impose some quite considerable code complexity on the app,
especially where the number of updated fields is large. It's fragile and
error-prone. A simple switch that can turn a trigger on or off will be
nicer. Syntax support for that might be even nicer, but there appears to
be some resistance to that, so I can easily settle for the trigger.
cheers
andrew
