On Nov 8, 2007, at 10:46 , Andrew Dunstan wrote:
Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
