[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [GENERAL] AW: [HACKERS] TRANSACTIONS
From: Jose Soares <jose () sferacarta ! com>
Date: 2000-02-28 8:44:57
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>Peter Eisentraut wrote:
<blockquote TYPE=CITE>On Thu, 24 Feb 2000, Jose Soares wrote:
<p>> NOTICE: (transaction aborted): all queries ignored until end
of transaction block
<br>>
<br>> *ABORT STATE*
<p>> Why PostgreSQL doesn't make an implicit ROLLBACK instead of waitting
for a
<br>> COMMIT/ROLLBACK ?
<p>The PostgreSQL transaction paradigm seems to be that if you explicitly
<br>start a transaction, you get to explicitly end it. This is of course
at
<br>odds with SQL, but it seems internally consistent to me. I hope that
one
<br>of these days we can offer the other behaviour as well.
<p>> Why PostgreSQL allows a COMMIT in this case ?
<p>Good question. I assume it doesn't actually commit though, does it?
I
<br>think a CHECK_IF_ABORTED (sp?) before calling the commit utility routine
<br>would be appropriate. Anyone?
<br> </blockquote>
Seems that PostgreSQL has a basically difference from other databases,
it has two operation modes
<br>"<b><u>transaction mode</u></b>" and "<b><u>non-transaction mod</u>e</b>".
<br>If you want initialize a transaction in PostgreSQL you must declare
it by using the BEGIN WORK
<br>statement and an END/ABORT/ROLLBACK/COMMIT statement to terminate the
transaction and switch from "<b><u>transaction mode</u></b>" to \
"<b><u>non-transaction mode</u></b>".
<br>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.
<br>Should it be the real problem with transactions ?
<blockquote TYPE=CITE>
<br>--
<br>Peter Eisentraut
Sernanders vaeg 10:115
<br>peter_e@gmx.net
75262 Uppsala
<br><a href="http://yi.org/peter-e/">http://yi.org/peter-e/</a>
Sweden
<p>************</blockquote>
<p>--
<br>Jose' Soares
<br>Bologna, Italy
Jose@sferacarta.com
<br> </html>
************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic