Updateable cursors are used as follows:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
PostgreSQL doesn't support this feature now ( 8.1.4). Will PGSQL
support it
On Mon, 24 Jul 2006, Golden Liu wrote:
Updateable cursors are used as follows:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
PostgreSQL doesn't support this
Gavin Sherry wrote:
On Mon, 24 Jul 2006, Golden Liu wrote:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
No one has stepped up to do this for 8.2 so unfortunately
Florian G. Pflug [EMAIL PROTECTED] 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,
Florian G. Pflug wrote:
Gavin Sherry wrote:
On Mon, 24 Jul 2006, Golden Liu wrote:
begin;
declare foo cursor for select * from bar for update;
fetch foo;
update bar set abc='def' where current of foo;
fetch foo;
delete from bar where current of foo;
commit;
No one has stepped up to
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] 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
Alvaro Herrera [EMAIL PROTECTED] writes:
No, a concurrent vacuum can't change that because vacuum can't change
the page unless it can get a super-exclusive lock on it (which means
nobody else can have a scan stopped at that page, which is exactly
what this cursor has).
More to the point,
Florian G. Pflug [EMAIL PROTECTED] writes:
How could there be a concurrent update of the _same_ row, when
I do select * from bar *for update*.
AFAICT the spec doesn't require one to have written FOR UPDATE
in order to use WHERE CURRENT OF. (In effect, they expect FOR UPDATE
to be the default,
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
How could there be a concurrent update of the _same_ row, when
I do select * from bar *for update*.
AFAICT the spec doesn't require one to have written FOR UPDATE
in order to use WHERE CURRENT OF. (In effect, they expect FOR UPDATE
