X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id AA7A0D1B8B3 for ; Mon, 1 Sep 2003 02:15:12 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 84615-10 for ; Sun, 31 Aug 2003 23:14:44 -0300 (ADT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by svr1.postgresql.org (Postfix) with SMTP id 8D992D1B8B0 for ; Sun, 31 Aug 2003 23:14:34 -0300 (ADT) Received: from pcp01341166pcs.wilog301.pa.comcast.net (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 Sep 2003 02:14:35 -0000 Received: from Yahoo.com (pcp01341166pcs.wilog301.pa.comcast.net [68.80.245.191]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h812DW102548; Sun, 31 Aug 2003 22:13:32 -0400 Message-ID: <3F52AAF2.2000104@Yahoo.com> Date: Sun, 31 Aug 2003 22:12:02 -0400 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Chris Anderson , pgsql-sql@postgresql.org Subject: Re: BEFORE UPDATE Triggers References: <69957C94-D9A1-11D7-8266-000393D3B384@pobox.com> <3F5010EB.9080807@black-lion.info> <2691.1062280587@sss.pgh.pa.us> In-Reply-To: <2691.1062280587@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/362 X-Sequence-Number: 14978 Tom Lane wrote: > Jan Wieck writes: >> Unfortunately, you're right. There is no way do distinguish in a trigger >> or rule if a value in the new row did result from the UPDATE query or >> from target list expansion with OLD values. > >> It would not be terribly hard to examine the original query during >> executor start, looking for bare OLD referencing Var nodes, and stick >> something like a flag array into the trigger information. > > People keep suggesting this, but I've never thought it was a very sane > idea. What if some BEFORE trigger upstream of yours changes the column? > You won't find that out unless you actually compare the OLD and NEW > column values. If you assume the column has not changed just because > the original query text didn't change it, you are in for a world of hurt. That's exactly why I allways ask to look at it from a business process point of view. The NEW data that will be persistent when the transaction commits has to match the new status of the business process. Where this data exactly is coming from, got manipulated or how it got there is not really relevant. What counts is that the system transforms from one consistent state into another in an ACID transaction. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #