|From:||Michael Meskes <meskes(at)postgresql(dot)org>|
|To:||PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>, zb(at)cybertec(dot)at|
|Subject:||Problems with variable cursorname in ecpg|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
I did some more testing on ecpg and found that allowing variables as cursor
names seems to produce more problems than I anticipated. But then maybe it's
just some missing checks to throw out error messages. Anyway, I attach a small
test program that, from my understanding, should work, but dosn't. Could
somebody with access to embedded SQL precompilers from other DBMSes please try
if this test case works with them?
The problem we seem to have right now comes from the original logic in ecpg
moving the declare cursor statement to the position of the open cursor
statemend at compile time. With the cursor name being unique this never has
been a problem. However, with variables as cursor names, this uniqueness need
not hold anymore. If it does, i.e. each cursor gets its own variable, all is
well, but if not, it doesn't work correctly at all times.
BTW I can modify the test case so it works fine, but ecpg will still throw an
error message, which is not a good situation either.
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
|Next Message||Andrew Dunstan||2010-03-29 12:06:38||Re: Proposal: Add JSON support|
|Previous Message||Łukasz Dejneka||2010-03-29 11:18:04||Using HStore type in TSearch|