From: | Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: How to notice column changes in trigger |
Date: | 2003-03-07 18:10:14 |
Message-ID: | 3E68E086.6020303@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-07 18:26:38 | Re: Cancelling Queries |
Previous Message | Josh Berkus | 2003-03-07 17:48:45 | Re: problem with subselect |