Am Mittwoch, 16. Mai 2001 21:29 schrieb Jan Wieck:
> For the EXCEPTIONS thing, well that's another issue. We could
> of course simulate/generate some of the exceptions like "no
> data found" and the other one I forgot (telling that a SELECT
> INTO returned multiple results). But we cannot catch a
> duplicate key error, a division by zero or a referential
> integrity violation, because when it happens a statement is
> half way done and the only way to cleanup is rolling back the
> entire transaction (for now, Vadim is working on savepoints).
> So I suggest you don't spend much of your time before we have
> them.
OK, I understand. For the beginning I only would like to have a possibility,
to catch any exception and create my own error handling, ignoring any
transaction-stuff. Because I have to port Procedures from Oracle to
PostgreSQL, I am looking, to imitate the way Oracle takes.
As I understand with my actual knowledge, this would mean, that every(!) call
of elog, which terminates the process, has to be caught. But this seems to
great for a new Postgres-hacker, like I am. Or do you see any other
possibility (maybe extending PLpgSQL_execstate)?
CU, Klaus
