Thanks so much tom! I feel a lot better going with this fix now that I know for
sure what was going wrong.
-- Brian
On May 26, 2012, at 8:08 PM, Tom Lane wrote:
> Brian Palmer writes:
>> The final line, the select, will return the row as it was before the
>> function ran, (1,0) instead of (1
Brian Palmer writes:
> The final line, the select, will return the row as it was before the
> function ran, (1,0) instead of (1,1). It's as if the outer select
> locked its view of the table in place before the inner select ran.
Yes, that's exactly correct. A plain SELECT always returns data th
On May 26, 2012, at 7:45 PM, Chris Angelico wrote:
> I'd be inclined to treat it like C and avoid referencing and
> altering a variable in one expression (eg arr[i++]=i; is a bad idea).
I agree, we're already working on changing it to a two-step process where we
select f1(), and then select * wh
On Sun, May 27, 2012 at 11:36 AM, Brian Palmer wrote:
> That's a good link, thanks Chris. I'm not sure it entirely answers what I'm
> seeing though. It does explain why the outer select doesn't see the updated
> values, but the other thing that I'm seeing is that sometimes the function
> will upda
On May 26, 2012, at 5:22 PM, Chris Angelico wrote:
> The function is actually immaterial to this; the same thing occurs
> with this single statement:
>
> with t1upd as (update t1 set b = b + 1 where b < 1 returning a) select
> * from t1 join t1upd using (a);
>
> Poking around with the latter for
On Sun, May 27, 2012 at 8:17 AM, Brian Palmer wrote:
> There is behavior in the following code that has me confused, and I'd like to
> understand it, as it goes against how I thought that MVCC worked in psql:
> ...
> select a from t1 into ret where b < 1 for update;
> update t1 set b =
