Re: Suggestion - Mailing list pgsql-advocacy

From Gandalf
Subject Re: Suggestion
Date
Msg-id 4050C2B7.40405@geochemsource.com
Whole thread Raw
In response to Suggestion  (Gandalf <gandalf@geochemsource.com>)
Responses Re: Suggestion
List 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 by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Comparison of PGSQL and DB2
Next
From: Peter Eisentraut
Date:
Subject: Re: Comparison of PGSQL and DB2