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
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). |