I don't see how. It is a fairly complicated program, and the perl calls are done through an API, which works fine in all other circumstances (I was told I had to use an API, and not use the Perl calls directly).
I moved the code in the function inline into the code, and I still cannot find the newly inserted id the next time through the loop. I think I'm just going to have to commit each time through the loop, although I really hate to. Maybe I can keep a list of the newly inserted rows, and delete them if anything goes wrong later in the loop. Thanks, Susan On Thu, Apr 17, 2014 at 8:13 AM, Scott Marlowe <scott.marl...@gmail.com>wrote: > So any chance of a self-contained test case so we're not all chasing our > tails? > > On Thu, Apr 17, 2014 at 9:06 AM, Susan Cassidy > <susan.cass...@decisionsciencescorp.com> wrote: > > Except for the fact that I get the new id returned from the first insert, > > which means that the insert probably did happen. > > > > Susan > > > > > > On Wed, Apr 16, 2014 at 11:55 PM, Alban Hertroys <haram...@gmail.com> > wrote: > >> > >> On 17 Apr 2014, at 2:49, David G Johnston <david.g.johns...@gmail.com> > >> wrote: > >> > >> > Robert DiFalco wrote > >> >> Two common cases I can think of: > >> >> > >> >> 1. The PERL framework is only caching the insert and does not > actually > >> >> perform it until commit is issued. > >> > > >> > Wouldn't the same mechanism cache the corresponding SELECT? > >> > >> Not likely, or if it did it wouldn't be able to know what id was > returned > >> from the function (which calls nextval(), but that isn't relevant here > since > >> it's marked volatile). > >> That makes it a possible scenario for what's being witnessed here. > >> > >> Alban Hertroys > >> -- > >> If you can't see the forest for the trees, > >> cut the trees and you'll find there is no forest. > >> > >> > >> > >> -- > >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > >> To make changes to your subscription: > >> http://www.postgresql.org/mailpref/pgsql-general > > > > > > > > -- > To understand recursion, one must first understand recursion. >
