Re: Re: any way for a transaction to "see" inserts done earlier in the transaction?

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(dot)cassidy(at)decisionsciencescorp(dot)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 <haramrae(at)gmail(dot)com> wrote:
>>
>> On 17 Apr 2014, at 2:49, David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>

--
To understand recursion, one must first understand recursion.