Thanks Tom. The work-around was to create the "script" in SQL -- using SELECT INTO statements to capture the key values -- instead of creating the "script" as a stored procedure.
Seems like a "transaction" issue. Having transactions occur at the SELECT level is very intuitive and a really nice, "protect-us-from-ourselves" feature that I'm not sure I'd want to mess with. Having the ability to execute a stored procedure outside the scope of a SELECT would ultimately resolve this. A topic for another day ... unless I missed something in an update somewhere. Anyway, thanks again. > "Martin Crundall" <[EMAIL PROTECTED]> writes: >> Some of the data tables have "AFTER INSERT" TRIGGERs on them that, >> in >> turn, insert some subordinate items into parallel data tables and the >> central pointer/ordering table. > > It looks to me like AFTER triggers are fired upon return to the main > loop in postgres.c, thus only at the end of a querystring sent by the > client. This is perhaps wrong, but I'm not sure that allowing them to > fire during plpgsql functions would be a good thing either. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
