Re: Disable Transaction - plans ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: 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 01:29:36
Message-ID: 1190.1003973376@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mike Mascari <mascarm(at)mascari(dot)com> writes:
> So would it be
> possible to modify PQFinish() to examine whether autocommit = true,
> and if so, issue a commit before disconnect, else just disconnect?

That's just a slightly different way of shooting yourself in the foot.
What's the difference whether it's libpq or the backend that pulls
the trigger? It's still not an explicit decision by the client.

I guess I do not understand the motivation for this proposal.
As I see it, the idea is that the client does not want an autocommit,
so he sets an option saying "no autocommit, hold transaction open until
I explicitly commit". Why exactly would such a client think that an
autocommit on disconnect is a good idea? The whole POINT is to require
an explicit commit command. (ie, the client wants the gun in his own
hand, no delegation of the trigger decision, thank you very much)

ISTM people who like autocommit will be using our existing behavior.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alex Pilosov 2001-10-25 01:42:28 Re: Record
Previous Message Hiroshi Inoue 2001-10-25 01:23:31 Re: [GENERAL] Using an SMP machine to make multiple indices on