Re: Suggestion

From: Gandalf <gandalf(at)geochemsource(dot)com>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Suggestion
Date: 2004-03-11 19:49:11
Message-ID: 4050C2B7.40405@geochemsource.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Chris Browne 2004-03-11 20:11:46 Re: Org Types, was: The big MySQL spin
Previous Message Bruno Wolff III 2004-03-11 19:47:02 Re: Comparison of PGSQL and DB2