| From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mike Mascari <mascarm(at)mascari(dot)com>, thomas(at)pgsql(dot)com, Doug McNaught <doug(at)wireboard(dot)com>, "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>, Ben-Nes Michael <miki(at)canaan(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Disable Transaction - plans ? |
| Date: | 2001-10-25 00:34:32 |
| Message-ID: | 3BD75E18.E971F0A3@fourpalms.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> > In fact, some could argue that the default behavior of PostgreSQL
> > should be changed (or at least have an option) to behave like
> > Oracle, where a transaction is implicitly begun at the first
> > encounter of an INSERT/UPDATE/DELETE - or in PostgreSQL's case, the
> > first submitted statement.
> If we put in an implicit BEGIN at the start of a connection, when
> does it get committed? We certainly dare not do an implicit COMMIT
> when the client disconnects, but without that the change would
> completely break a lot of existing applications.
Ingres solved this with a mode switch; "set autocommit on|off" which is
in the style that we would likely use too. It *should* be optional, but
settable, and we can debate which should be the default later.
When autocommit is "off", the transaction gets committed when you exit
or when you explicitly commit.
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-10-25 00:39:58 | Re: Disable Transaction - plans ? |
| Previous Message | Bruce Momjian | 2001-10-25 00:32:14 | Re: [GENERAL] CVS server stumbling? |