Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 37544476CD8
	for <pgsql-sql@postgresql.org>; Wed, 18 Dec 2002 11:34:11 -0500 (EST)
Received: from davinci.ethosmedia.com (unknown [209.10.40.251])
	by postgresql.org (Postfix) with ESMTP id C3C3B476A41
	for <pgsql-sql@postgresql.org>; Wed, 18 Dec 2002 11:30:21 -0500 (EST)
Received: from [63.195.55.98] (account <josh@agliodbs.com>)
	by davinci.ethosmedia.com (CommuniGate Pro WebUser 4.0.2)
	with HTTP id 2290387; Wed, 18 Dec 2002 08:30:09 -0800
From: "Josh Berkus" <josh@agliodbs.com>
Subject: Re: pl/pgsql question
To: Tim Perdue <tim@perdue.net>,
	Ludwig Lim <lud_nowhere_man@yahoo.com>
Cc: PostgreSQL Mailing List <pgsql-sql@postgresql.org>
X-Mailer: CommuniGate Pro Web Mailer v.4.0.2
Date: Wed, 18 Dec 2002 08:30:09 -0800
Message-ID: <web-2290387@davinci.ethosmedia.com>
In-Reply-To: <3E008003.1030402@perdue.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by AMaViS new-20020517
X-Archive-Number: 200212/222
X-Sequence-Number: 10810

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.

-Josh