I assume don't want a TODO for this? (Suppress UPDATE no changed columns)
--------------------------------------------------------------------------- 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. > > cheers > > andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
