Re: Suggestion
От | Gandalf |
---|---|
Тема | Re: Suggestion |
Дата | |
Msg-id | 4050C2B7.40405@geochemsource.com обсуждение исходный текст |
Ответ на | Suggestion (Gandalf <gandalf@geochemsource.com>) |
Ответы |
Re: Suggestion
|
Список | pgsql-advocacy |
> > >> >> I don't know if this is the right place to write. I was redirected >> here from the psycopg list (a Python PostgreSQL interface). >> They told me what I want is not to be done in the python extension >> lib because it is in the heart of PostgreSQL. >> >> Here is my problem. Every time an error occurs (e.g. I try to execute >> a SQL query and it fails) something happens to the backend. >> It is starting not to execute further commands in the same transaction. >> > > It is because the transaction has failed and thus rolledback. We do > not support nested transactions. Sorry, this was not my question, I was not clear though. By the way, I'm looking forward for nested transactions. I read about WAL and I know that at some point we will have nested transactions in PostgreSQL. Consider this (where cmd2 is an atomic UPDATE but the others can be complex): try: cmd1; try: cmd2; failed = false; except: failed = true; end if failed then cmd3; else cmd4; commit; except rollback; end Is it really a nested transaction? There is only one COMMIT and one ROLLBACK. You can try this in FireBird or MS SQL or Oracle. They will gladly execute cmd3 or cmd4 and then commit all changes (except the failed atomic cmd2). I personally know that the most silly FireBird does not support nested transactions but it can do this. This example is without executing CHECKPOINT and ROLLBACK TO so I think it is not a real nested transaction problem. It is about not rolling back the transaction automatically when a single command fails. In fact, I wrote many graphical applications and all of them used this feature without using real nested transactions. Maybe I have a complete notion failure. :-) Best, G
В списке pgsql-advocacy по дате отправления: