On Mon, Jan 19, 2009 at 12:53 AM, Grzegorz Jaśkiewicz <gryz...@gmail.com> wrote: > 2009/1/19 Scott Marlowe <scott.marl...@gmail.com>: >> Submit a patch. :) >> >> But seriously, it's doing what you told it to do. There might be >> corner cases where you need a trigger to fire for a row on change, and >> short-circuiting could cause things to fail in unexpected ways. > > as far as my little knowledge about pg goes, that would be just > another addition to planner. <daydreaming> Say - when there's more > than X % of value Y, and we do set column X to Y, it could add that > 'where'. But what if we have more WHERE statements, and they are quite > contradictory, etc, etc. It could actually do more damage than good. > (yes, I do have quite few more 'against' than for)</daydreaming>
Yes, but what about a table with an update trigger on it that does some interesting bit of housekeeping when rows are updated? It might be that you have ten rows, all with the number 4 in them, and you update the same field again to 4. With the trigger some other processing gets kicked off and some maintenance script picks up those values and does something. If the db autoshort-circuited like you want, the trigger would never fire. According to the strictest interpretation, setting a value from 4 to 4 is still a change. But the database just changed the rules underneath you. It's a prime example of fixing a problem created by not knowing how the database works, and creating a possible problem for people who do know how it works. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
