Re: Nested Transactions, Abort All
От | Bruce Momjian |
---|---|
Тема | Re: Nested Transactions, Abort All |
Дата | |
Msg-id | 200407110025.i6B0PGK19342@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Nested Transactions, Abort All (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Nested Transactions, Abort All
Re: Nested Transactions, Abort All Re: Nested Transactions, Abort All |
Список | pgsql-hackers |
Josh Berkus wrote: > > Well, that involves either creating a conditional capability in the > > backend, or in psql, neither of which will happen for 7.5. The best we > > can do is allow COMMIT NESTED INGORE ERROR (or COMMIT NESTED INGORE > > ROLLBACK) and just let the script keep going. I am thinking of cases > > where you want to drop an object you aren't sure exists in a > > transaction. Anything more complicated like issuing a replacement query > > will have to wait for 7.6. > > OK, I didn't realize that it was a difficult thing. I think it should go on > the TODO list but you are the judge of what's a quick fix and what's not. > > (BTW, aside from this limitation, I am *not* in favor of COMMIT NESTED IGNORE > ERROR) OK, no one likes that idea, so let's forget it. Do we want to allow BEGIN NESTED to start a main transaction? Oracle can use SAVEPOINTS all the time because it knows it is always in a transaction, but PostgreSQL is not always. I don't see a downside to allowing it. COMMIT will still commit the entire transaction, of course. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: