Re: Grammar-problems with pl/pgsql in gram.y

From: Klaus Reger <K(dot)Reger(at)gmx(dot)de>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>, K(dot)Reger(at)gmx(dot)de
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Grammar-problems with pl/pgsql in gram.y
Date: 2001-05-18 13:31:35
Message-ID: 200105181331.f4IDVck23897@pc01.reger-clan.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-05-18 13:47:55 Re: AW: Plans for solving the VACUUM problem
Previous Message Adrian Phillips 2001-05-18 13:07:14 Re: Upgrade issue (again).