Re: 7.3beta and ecpg - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: 7.3beta and ecpg
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E81@m0114.s-mxs.net
Whole thread Raw
In response to 7.3beta and ecpg  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
> 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
usethe 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
preparedstatements where    you don't directly use host variables in the statement, but placeholders ("?").4. we did
usethe 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


pgsql-hackers by date:

Previous
From: Oliver Elphick
Date:
Subject: Re:
Next
From: Bruce Momjian
Date:
Subject: Re: