From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Golden Liu <goldenliu(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name |
Date: | 2006-07-24 15:34:08 |
Message-ID: | 44C4E870.6030005@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> Couldn't this be emulated by doing
>> begin;
>> declare foo cursor for select * from bar for update;
>> fetch foo into v_foo ;
>> update bar set abc='def' where ctid = v_foo.ctid;
>
> That wouldn't follow the expected semantics if there's a concurrent
> update, because the updated row would always fail the WHERE clause,
> and thus the update would just silently not happen. (I'm thinking
> about READ COMMITTED mode of course --- in SERIALIZABLE you'd just get
> the expected error.) You'd have to find some way to pump the row's most
> up-to-date version through the cursor's query plan, a la EvalPlanQual,
> to see if it still met the cursor's WHERE condition.
How could there be a concurrent update of the _same_ row, when
I do "select * from bar *for update*". Or are you talking about
concurrent updates to the same page that could somehow alter
the ctid of _another_ tuple?
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-07-24 15:38:31 | Re: Better name/syntax for "online" index creation |
Previous Message | Alvaro Herrera | 2006-07-24 15:28:01 | Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name |