Message-ID: <3E00A5FE.7080300@perdue.net>
Date: Wed, 18 Dec 2002 10:44:46 -0600
From: Tim Perdue <tim@perdue.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.3a) Gecko/20021123
MIME-Version: 1.0
To: Josh Berkus <josh@agliodbs.com>
Cc: PostgreSQL Mailing List <pgsql-sql@postgresql.org>
Subject: Re: pl/pgsql question
References: <web-2290387@davinci.ethosmedia.com>
In-Reply-To: <web-2290387@davinci.ethosmedia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Josh Berkus wrote:
> Tim,
> 
> 
>>That loop apparently does not find any matching rows, which would
>>have been inserted just before this row was, inside the same
>>transaction.
>>
>>It was successfully finding those rows before, when the trigger was
>>AFTER INSERT. If I manually select those rows after the query is
>>committed, I am able to pull up the matching rows.
> 
> 
> I think that triggers are probably not a good strategy for the kind of
> calculation you're doing.  I'd suggest instead a middleware module or a
> "data push" function which would bundle all of the calculation logic
> before calling any of the inserts.

Yeah, but this is so much cooler. ;-)

Essentially this would be like recursion to push back/pull forward tasks 
which are dependent on each other. The "UPDATE" trigger I wrote is about 
5x longer.

I guess I can push this back into the PHP code and do a recusive 
function call, but that seems less sexy.

Tim