Thread

1. ecpg news

   Michael Meskes <meskes@topsystem.de> — 1998-02-24T12:26:52Z

   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
   
   

2. Re: [HACKERS] ecpg news

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-02-24T13:45:05Z

   > 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
   
   
   

3. Re: [HACKERS] ecpg news

   Michael Meskes <meskes@topsystem.de> — 1998-02-24T16:05:34Z

   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