Re: 7.3beta and ecpg

> We can revisit that decision if you like, but you must convince us that
> it was wrong, not just say "of course we should change it".

I am sorry, but at that time I did not have time for the discussion,
and now is also very tight for me :-(

Four reasons I can give:
1. execute xx(...); looks like xx is a procedure which it definitely is not.
2. imho ecpg should use the backend side feature and thus the syntax should be
the same. iirc the syntax was chosen to separate it from esql, but if it gets
to be the same why separate it ?
3. I think a close comparison is possible for dynamically prepared statements where
you don't directly use host variables in the statement, but placeholders ("?").
4. we did use the esql standard for "declare cursor", why not now ?

Are the () mandatory for the backend side feature ? If yes, it would at least be possible
to differentiate ecpg from it.

Actually "exec sql execute" is only for statements not returning a result set (e.g. update).
selects would need 'declare "curid" cursor for ...' and fetch, but that would imho be an
improvement because you can then choose a named portal.

Andreas