On Nov 8, 2007, at 10:46 , Andrew Dunstan wrote:
>
>
> 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.
This confirms what I thought. Thanks.
Michael Glaesemann
grzm seespotcode net
