Message-ID: <3E68E086.6020303@web.de>
Date: Fri, 07 Mar 2003 19:10:14 +0100
From: Andreas Pflug <Andreas.Pflug@web.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: How to notice column changes in trigger
References: <3E6874CD.4090501@web.de> <200303070941.41276.josh@agliodbs.com>
In-Reply-To: <200303070941.41276.josh@agliodbs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Josh Berkus wrote:

>Andreas,
>
>  
>
>>1) update test set a=0 -> trigger does its work
>>2) update test set a=0, b=1, c=2 -> trigger does nothing
>>3) update test set a=0, b=b, c=c -> trigger does nothing, but content of
>>a and b dont change either although touched
>>    
>>
>
>  
>
>>IF OLD.b=NEW.b will not work, case 3) will falsely execute the trigger
>>code.
>>    
>>
>
>I still don't get why you'd want to do this.   Can you provide are real-world 
>example where there is a difference between setting B=B and not updating B?
>
>  
>
I do.
It's about tracking changing user and timestamp. Normally, all inserts 
and updates won't touch the b and c columns, and they are handled using 
triggers and/or default values.But sometimes, I'd like to update some 
columns (other than b or c) WITHOUT having changed b or c. This could 
happen for some import tasks, for example. In this case, the 
user/timestamp from the exporting database should be replicated, not 
altered. In other cases, some maintenance procedure should calculate a 
column different from b and c, which would lead to timestamp set to lets 
say midnight, and the user to "serviceProcess" which would destroy the 
original data. In this case, I'd set b and c to the original data. 
That's the way I can handle this with MSSQL.