Re: [GENERAL] AW: [HACKERS] TRANSACTIONS - Mailing list pgsql-general

From Jose Soares
Subject Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
Date
Msg-id 38BA3589.F665A695@sferacarta.com
Whole thread Raw
In response to Re: [GENERAL] AW: [HACKERS] TRANSACTIONS  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
List pgsql-general
 
Peter Eisentraut wrote:
On Thu, 24 Feb 2000, Jose Soares wrote:

> NOTICE:  (transaction aborted): all queries ignored until end of transaction block
>
> *ABORT STATE*

> Why PostgreSQL doesn't make an implicit ROLLBACK instead of waitting for a
> COMMIT/ROLLBACK ?

The PostgreSQL transaction paradigm seems to be that if you explicitly
start a transaction, you get to explicitly end it. This is of course at
odds with SQL, but it seems internally consistent to me. I hope that one
of these days we can offer the other behaviour as well.

> Why PostgreSQL allows a COMMIT in this case ?

Good question. I assume it doesn't actually commit though, does it? I
think a CHECK_IF_ABORTED (sp?) before calling the commit utility routine
would be appropriate. Anyone?
 

Seems that PostgreSQL has a basically difference from other databases, it has two operation modes
"transaction mode" and "non-transaction mode".
If you want initialize a transaction in PostgreSQL you must declare it by using the BEGIN WORK
statement and an END/ABORT/ROLLBACK/COMMIT statement to terminate the transaction and switch from "transaction mode" to "non-transaction mode".
The SQL92 doesn't have such statement like BEGIN WORK because when you initialize a connection to a database you are all the time in transaction mode.
Should it be the real problem with transactions ?
 
--
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

************

--
Jose' Soares
Bologna, Italy                     Jose@sferacarta.com
 

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: open pgsql files (was Re: [GENERAL] Mime-Version: 1.0)
Next
From: "Henrique Pantarotto"
Date:
Subject: RES: [GENERAL] Stored procedures returning multiple values... ?