Message-ID: <3EAA483E.2060204@web.de>
Date: Sat, 26 Apr 2003 10:50:06 +0200
From: Andreas Pflug <Andreas.Pflug@web.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: Josh Berkus <josh@agliodbs.com>, pgsql-sql@postgresql.org
Subject: Re: Statement triggers 7.4 NEW/OLD
References: <3EA7CD6A.9080404@web.de> <3EA9EFA3.EF4C0D1@Yahoo.com>
	<200304252120.01644.josh@agliodbs.com>
In-Reply-To: <200304252120.01644.josh@agliodbs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Josh Berkus wrote:

>>IMHO statement triggers instead should have access to the NEW and OLD
>>rows through some mechanism. I can think of NEW and OLD being reference
>>cursors in the case of statement triggers, and the trigger then can
>>FETCH the rows from there.
>>    
>>
>
>Yeah; how else could it possibly work?
>
>  
>
Why do it easy if you can have it difficult? ;-) If I want to perform 
row by row actions I use a row level trigger!
Statement triggers need to work like this:
Instead of
    NEW.foo := 1;
you code
    UPDATE NEW SET foo=1;
If the statement trigger doesn't offer a complete SETOF RECORD, It's 
pretty useless.
In my case, updates and deletes on a table could possibly touch 
thousands of rows at the same time, and the trigger will update 
aggregated values in another table, and insert or delete a third one 
with 3-4 additional statements. This is pretty fast if implemented as 
true statement trigger, but will possibly blow the system if done row by 
row. Imagine a single statement, that triggers ROW_COUNT*4 statements, 
where ROW_COUNT can easily be 1000, 10000 or much more!

Regards,
Andreas