From: | Tim Perdue <tim(at)perdue(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL Mailing List <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: pl/pgsql question |
Date: | 2002-12-18 16:44:46 |
Message-ID: | 3E00A5FE.7080300@perdue.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Myrta | 2002-12-18 16:46:48 | Re: references table(multiple columns go here) |
Previous Message | Josh Berkus | 2002-12-18 16:30:09 | Re: pl/pgsql question |