> 1. The statement
> 
>     UPDATE table SET fld1 = :input1
>     WHERE CURRENT OF :curname
>     RETURNING id + :input2;
> 
>     is transformed into
> 
>     UPDATE table SET fld1 = $1
>     WHERE CURRENT OF $0
>     RETURNING id + $2;
> 
>     and the $0 is past $1. The current code cannot deal with such
>     a messed up order, and scanning the original query twice is
>     needed, once for $0 substitution, once for mapping $1, etc. to
>     the other input variables.

I cannot seem to reproduce this bug. Could you please send me an example that
makes this reproducible? Yes, I know that I have to change preproc.y to allow
for variable cursor names but in my test case everything seems to work well and
$0 gets replaced by the cursor name.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes(at)jabber(dot)org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

In response to

• ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname at 2010-08-03 17:01:48 from Boszormenyi Zoltan

Responses

• Re: Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname at 2010-10-27 14:22:43 from Boszormenyi Zoltan

pgsql-hackers by date

Next:	From: Cristian Bittel	Date: 2010-09-01 14:49:52
	Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session
Previous:	From: Heikki Linnakangas	Date: 2010-09-01 14:39:53
	Subject: Re: register/unregister standby Re: Synchronous replication