| 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: | Whole Thread | Raw Message | 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). |