Re: [HACKERS] ecpg news

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Michael Meskes <meskes(at)topsystem(dot)de>
Cc: PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] ecpg news
Date: 1998-02-24 13:45:05
Message-ID: 34F2CEE1.E702CC35@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

  • ecpg news at 1998-02-24 12:26:52 from Michael Meskes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim B. Mikheev 1998-02-24 14:56:12 some problems with new locking code
Previous Message Frank Ridderbusch 1998-02-24 13:39:40 Using the -u switch for diff in regress.sh