>> Shouldn't we change default transaction mode now?>> And use option/SET TRANSACTION MODE to switch to>>
un-chainedmode if one like it?>>No comments on this?>I would like to make BEGIN implicit...>Objections?
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
is sufficient.Therefore most clients don't need the extra set transaction
isolation statement.
As to transaction blocks: Actually most clients never use commit work, and rememberthat postgresql will never free it's
memorybefore commit. This will
hog up memory for otherwise lightweight clients.
I also think that the begin work; commit work; statement block issomewhat part of the postgresql philosophy. We do not
standalonewith this approach (Informix).Actually the other DB's start the transaction with the first
modifying statement, in my opinion a rather weird approach. I have seen programs that do a dummy update, just to
simulatea 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
an implicittemp table).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
changeable default at database level.
Andreas