On Mon, Jan 19, 2009 at 12:53 AM, Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx> wrote:> 2009/1/19 Scott Marlowe <scott.marlowe@xxxxxxxxx>:>> 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 doessome interesting bit of housekeeping when rows are updated? It mightbe that you have ten rows, all with the number 4 in them, and youupdate the same field again to 4. With the trigger some otherprocessing gets kicked off and some maintenance script picks up thosevalues and does something. If the db autoshort-circuited like youwant, the trigger would never fire. According to the strictestinterpretation, setting a value from 4 to 4 is still a change. Butthe database just changed the rules underneath you. It's a prime example of fixing a problem created by not knowing howthe database works, and creating a possible problem for people who doknow how it works. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general
