X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5C1363A5EB4 for ; Thu, 27 Jan 2005 15:06:41 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 71171-09 for ; Thu, 27 Jan 2005 15:06:32 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 0B6F43A5D92 for ; Thu, 27 Jan 2005 15:06:35 +0000 (GMT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0RF6Wd9019795; Thu, 27 Jan 2005 10:06:33 -0500 (EST) To: Wilton Cc: pgsql-sql@postgresql.org Subject: Re: Complete instruction in a trigger In-reply-to: <41F8F477.7090100@microwork.inf.br> References: <41F8F477.7090100@microwork.inf.br> Comments: In-reply-to Wilton message dated "Thu, 27 Jan 2005 11:02:31 -0300" Date: Thu, 27 Jan 2005 10:06:32 -0500 Message-ID: <19794.1106838392@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200501/293 X-Sequence-Number: 20081 Wilton writes: > I have a table "customers", then a user go there and change the customer > record, for example he changes the zip code column. Then I can know that > something changed into the "customer table", and send a full update of > that record through the web to the database that i want, but i need to > know what column had changed to send a update just for that column. But > i do not know in which column his has made that change. So, i need to > know the instruction to do this. Something like a specific update for > that column modified by the user. People ask for this often, and in every case I've seen, they would be wrong to depend on it if they had it. The reason is that the original SQL query is not sufficient information to tell which columns changed. Consider for example the possibility that the query was rewritten by a rule, or the new tuple was modified by another trigger that executed ahead of yours. The only correct way to determine which columns changed is to compare the OLD and NEW values of each column ... and you'd better do it in an AFTER trigger, not a BEFORE trigger, if you want to be certain that you are looking at the final result. regards, tom lane