>> Shouldn't we change default transaction mode now?
>> And use option/SET TRANSACTION MODE to switch to
>> un-chained mode if one like it?
>No comments on this?
>I would like to make BEGIN implicit...
Yes, I object. I think the default behavior should be the one that
is sufficient in most cases.
As to the isolation level:
Informix and DB/2 default to read committed mode. In most cases this
Therefore most clients don't need the extra set transaction
As to transaction blocks:
Actually most clients never use commit work, and remember
that postgresql will never free it's memory before commit. This will
memory for otherwise lightweight clients.
I also think that the begin work; commit work; statement block is
somewhat part of the postgresql philosophy. We do not stand alone
with this approach (Informix).
Actually the other DB's start the transaction with the first
statement, in my opinion a rather weird approach.
I have seen programs that do a dummy update, just to simulate a
begin work, what a waste.
But this alone will not work, because a select statement, that needs
a sort would have started the transaction earlier (Since it created
I could go on, but you see I don't really like this ......
If you want to change the behavior, I think we will need a
at database level.
pgsql-hackers by date
|Next:||From: Theo Kramer||Date: 1998-12-28 14:04:56|
|Subject: Re: [HACKERS] MVCC works in serialized mode!|
|Previous:||From: Angelos Karageorgiou||Date: 1998-12-28 08:27:55|
|Subject: Re: [HACKERS] psql \d does not work|