Thread: ecpg news
I'm back to having a working 6.3 installation since saturday night. It appears Jan's patches fixed my problem. Anyway, I've just submitted a patch that fixes all bugs I could reproduce. However, I cannot reproduce the problem with the varchar entry in a struct in test2.pgc. So if this still exists we have to dig into it in more detail. Also, I'm not sure about what the standard says for the whenever command. I'm pretty sure I already saw a 'exec whenever sqlerror break;' command maybe on Ingres. Oracle does not know about this. I tried implementing it regardless, but found that this is almost impossible since break obviously cannot be issued outside a loop resp. switch statement. Shall I just remove it? And the continue statement? Currently ecpg adds a continue command, but it appears to be better to do nothing in case the user wants to continue. This is btw what Oracle does too. Finally, here's a list of open bugs that I won't be able to tackle before 6.3 is released: - The return code is alway -1 in case of an error. You cannot see which error occured by examining the return code. - The cursor is opened when the declare statement is issued. - ecpg does not understand enum datatypes. - There is no exec sql prepare statement. - The complete structure definition has to be listed inside the declare section for ecpg to be able to understand it. - Each variable has to be defined on a line on its own. - There is no way yet to fill a complete array with one call except arrays of [unsigned] char which are considered strings. - ecpg cannot use pointer variables except [unsigned] char * Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> Also, I'm not sure about what the standard says for the whenever command.
> I'm pretty sure I already saw a 'exec whenever sqlerror break;' command
> maybe on Ingres. Oracle does not know about this. I tried implementing it
> regardless, but found that this is almost impossible since break obviously
> cannot be issued outside a loop resp. switch statement. Shall I just remove
> it?
The CA-Ingres parameters on "whenever" are only "continue", "stop", "goto
<label>", and "call <procedure>". I suspect that part of the problem is that
embedded SQL is available for several host languages, and some don't map the
same way as C would. How about disabling it for now?
> And the continue statement? Currently ecpg adds a continue command, but it
> appears to be better to do nothing in case the user wants to continue. This
> is btw what Oracle does too.
CA-Ingres sez:continue: continues execution with the next executable statement.
If a fatal error occurs, an error message is printed and the program aborts.
I think this means that errors are ignored, as in Oracle, rather than doing a
C-style "continue". Then, the program can check the sqlcode variable to decide
what to do...
> Finally, here's a list of open bugs that I won't be able to tackle before
> 6.3 is released:
The embedded SQL is a great capability which was one of the most visible
omissions in the Postgres features. Thanks for being so aggressive and
persistent about getting it solid for its first release. But, we've got to have
a few things to work on later :)
- Tom
Thomas G. Lockhart writes: > The CA-Ingres parameters on "whenever" are only "continue", "stop", "goto > <label>", and "call <procedure>". I suspect that part of the problem is that > embedded SQL is available for several host languages, and some don't map the > same way as C would. How about disabling it for now? Okay, I will do that as soon as I find time. > CA-Ingres sez:continue: continues execution with the next executable statement. > If a fatal error occurs, an error message is printed and the program aborts. > > I think this means that errors are ignored, as in Oracle, rather than doing a > C-style "continue". Then, the program can check the sqlcode variable to decide > what to do... Okay, will change that, too. In fact I like this approach much more than the continue statement. > The embedded SQL is a great capability which was one of the most visible > omissions in the Postgres features. Thanks for being so aggressive and > persistent about getting it solid for its first release. But, we've got to have > a few things to work on later :) My pleasure. Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10