Re: Problems with variable cursorname in ecpg

> The interpretation of the standard in the above way (DECLARE is declarative,
> ...

It's not just interpretation, but also a regression if we were to change this.

> The uniqueness problem can only be solved with modifying
> the runtime library to keep track of the cursor names in the client.
> It would ruin the declarative nature of DECLARE but would increase
> compatibility with Informix, and we would also need to implement
> correct "FREE cursorname" behaviour, too. Which would also bring
> the consequence that the ECPG client library would need to
> forbid cursors and prepared statements with the same name as
> "FREE" can also free cursors and prepared statements.

True.

> I think the current behaviour is the best we could achieve
> while keeping close standard conformance.

I think we should make the error message/documentation a little bit clearer as
people have stumbled over it. Having said that couldn't we keep the statement
declarative only for statements that do not carry a variable? This will not
break any onld program and besides using a variable that doesn't exist, because
you're outside a function doesn't make sense either. This is probably something
for 9.1 though if it indeed works.

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