From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Fernando Nasser <fnasser(at)redhat(dot)com> |
Cc: | snpe <snpe(at)snpe(dot)co(dot)yu>, pgsql-general(at)postgresql(dot)org, tgl(at)redhat(dot)com |
Subject: | Re: AutoCommit mode in PostgreSQL (7.3 beta1 from CVS 05.09.2002) |
Date: | 2002-09-10 01:53:14 |
Message-ID: | 200209100153.g8A1rEm01392@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Fernando Nasser wrote:
> I could not find the exact clause that says that in either SQL'92 nor
> SQL'99, but C.J.Date says (about SQL'92) says that a DISCONNECT would
> "automatically execute either a ROLLBACK or a COMMIT (it is
> implementation dependent which)".
>
> I guess a GUC variable can be a good idea, for Oracle compatibility
> purposes. I would make our default different from Oracle's though: if a
> commit is not received something is wrong, either an user error, some
> tool error, etc. It sees safer to ROLLBACK. Isn't that what we do if
> a connection is lost due to a communication error anyway? How can
> Oracle know that if it got the whole set of commands for the transaction
> anyway? Isn't there a more specific situation where it does that (the
> automatic COMMIT)?
>
> Anyway, psql can be smarter and ask the user: "There is a transaction in
> progress, do you want to commit?", what can be done
I agree with Tom. If you are in a multi-statement transaction, then if
you exit, you exit. I can't understand the logic that would to a commit
on any type of disconnect.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Ostrowski | 2002-09-10 01:55:40 | Re: describe table query? |
Previous Message | snpe | 2002-09-10 01:07:46 | Re: describe table query? |