Re: Sketch of extending error handling for subtransactions
От | Tom Lane |
---|---|
Тема | Re: Sketch of extending error handling for subtransactions |
Дата | |
Msg-id | 9386.1090722835@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Sketch of extending error handling for subtransactions (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Sketch of extending error handling for subtransactions
Re: Sketch of extending error handling for subtransactions |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > So it allows functions to use subtransactions and recover from errors. > I thought that was more than we could do for 7.5 and in fact the release > notes now saw that will be done in a future release. I think there's only a day or two's work between here and there, and it would be foolish not to have the feature if we can get it. As I see it, we need: 1. The elog.c factoring described in this thread. 2. An extension to the SPI API to allow execution of commands within a subtransaction, with catching of errors. 3. A bit of work on plpgsql to support some kind of EXCEPTION syntax. I might decide to forget about SPI and trap errors directly in plpgsql, but in any case it doesn't seem out of reach. I was just looking around the net to see exactly what Oracle's PL/SQL syntax is. It doesn't seem too unreasonable syntax-wise: BEGIN ... controlled statements ...EXCEPTION WHEN exception_name THEN ... error handling statements ... WHENexception_name THEN ... error handling statements ... ... WHEN OTHERS THEN ... error handling statements...END; There's nothing here we couldn't do. However, it seems that Oracle thinks you should throw in explicit SAVEPOINT and ROLLBACK statements on top of this! That's just weird. It might be that we should deliberately *not* adopt the exact syntax they are using, just so we don't create compatibility gotchas. regards, tom lane
В списке pgsql-hackers по дате отправления: