Re: Suggestion

[Gandalf <gandalf(at)geochemsource(dot)com>]

> > 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