> > 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 ?
>
> Maybe I misunderstood something. Do you mean I could use the backend
> PREPARE/EXECUTE to prepare and execute any statement I can
> PREPARE/EXECUTE with the ecpg part? Can I use PREPARE to prepare a
> cursor? In that case I will gladly remove the ecpg stuff.
That is how I understood it so far.
> I just looked into the backend any further and wonder why I didn't
> understand earlier. For some reason I was believing this was just an
> optimization command.
Well, yes and no. For programs the reuse a prepared statement it is
good, for those that only use it once it can be a loss. Simple tests in prev posts
to this list showed, that with longer data cstrings the parser was so slow,
that prepare + execute actually sped up the overall exec time. (At least that was
my interpretation)
>
> It seems I can use larger parts of this thus reducing ecpg parser's
> complexity as well.
Hopefully :-)
>
> > 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 :-(
>
> Actually ecpg needs 'execute id using ... into ...'. I did not see any
> mention of using in the backend execute command. The 'execute :idvar'
> part is easier since this correctly is named 'execute immediate :idvar'
> I think.
The "using" clause is optional, I just left it out. My ESQL/C precompiler
can also use an id variable for "execute :idvar using ...". That is actually
how we use esql/c here.
>
> AFAIK the standard is "execute ID using value" and not "execute
> ID(value)". Please correct me if I'm wrong, but right now ecpg uses the
> first syntax the backend uses the second.
I think it should be the intention to keep those identical, which would
mean, that the backend syntax is currently wrong :-(
Andreas
