From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Michael Meskes" <meskes(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL Hacker" <pgsql-hackers(at)postgresql(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
Subject: | Re: 7.3beta and ecpg |
Date: | 2002-09-11 09:23:45 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961E7E@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Actually there is one more problem. The backend introduced the EXECUTE
> command just recently. However, this clashes with the embedded SQL
> EXECUTE command. Since both may be called just with EXECUTE <name>,
> there is no way to distinguish them.
>
> I have no idea if there's a standard about execution of a plan but
> couldn't/shouldn't it be named "EXECUTE PLAN" instead of just
> "EXECUTE"?
I know this is not really related, but wouldn't the plan be to make
ecpg actually use the backend side "execute ..." now that it is available ?
ecpg needs eighter 'execute :idvar' or 'execute id', so either idvar is a
declared variable or id a statement id. I don't know if that is something a
parser can check though :-(
For now, I would leave "exec sql execute" do the ecpg thing if that is possible.
If you want to use the backend side functionality you would need to:
exec sql prepare ex1 from 'execute id';
exec sql execute ex1;
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2002-09-11 09:35:55 | Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue |
Previous Message | Michael Meskes | 2002-09-11 08:29:29 | Re: 7.3beta and ecpg |