Re: Nested Transactions, Abort All
От | Mike Mascari |
---|---|
Тема | Re: Nested Transactions, Abort All |
Дата | |
Msg-id | 40E5B88E.3040109@mascari.com обсуждение исходный текст |
Ответ на | Re: Nested Transactions, Abort All (Thomas Swan <tswan@idigx.com>) |
Список | pgsql-hackers |
Thomas Swan wrote: > Alvaro Herrera wrote: > >> Yes, I was thinking about this because the current code behaves wrong if >> a BEGIN is issued and not inside a transaction block. So we'd need to >> do something special in SPI -- not sure exactly what, but the effect >> would be that the function can't issue BEGIN at all and can only issue >> SUBBEGIN. >> > Isn't this counterintuitive. It seems that BEGIN and COMMIT/ABORT > should be sufficient regardless of the level. If you are inside a > current transaction those commands start a new transaction inside of the > current transaction level, just like pushing on and popping off elements > on a stack. How about this radical idea: Use SAVEPOINT to begin a subtransaction and ROLLBACK TO SAVEPOINT to abort that subtransaction. Normally, in Oracle, I would write code like: SAVEPOINT foo; <do work> IF (error) THEN ROLLBACK TO SAVEPOINT foo; END IF; Could we not treat a subtransaction as an "anonymous" savepoint until savepoints are added? So the above in PostgreSQL would read: SAVEPOINT; <do work> IF (error) THEN ROLLBACK TO SAVEPOINT; END IF; My old SQL3 draft EBNF reads: <savepoint statement> ::= SAVEPOINT <savepoint specifier> <savepoint specifier> ::= <savepoint name> | <simple target specification> <savepoint name> ::= <identifier> and <rollback statement> ::= ROLLBACK [ WORK ] [ AND[ NO ] CHAIN ] [ <savepoint clause> ] <savepoint clause> ::= TO SAVEPOINT <savepoint specifier> Mike Mascari
В списке pgsql-hackers по дате отправления: