Right. I don't know this code or DBI but many frameworks create a pool of ids using sequence generators so that they can minimize round trips and know the id of new records before the are written.
Sent from my iPhone > On Apr 17, 2014, at 8: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 >
