>One of the reasons for taking autocommit control out of the backend and
>pushing it up to the client level is exactly to make it feasible to take
>these sorts of application-level considerations into account when
>choosing the behavior.
Ok, I can see some sense in that: Make the autocommit-behavior client
dependent instead of system dependent. But that requires that all clients
the user uses can handle this (is able to store a default behavior).
I aggree, that clients should, as you write, overrule the system default
behavior. But I (still) can't find an argument for, why the administrator
should not have the oppotunity to set a default behavior for the whole
system (not even in the archives). In this way postgres would be able to
deal with clients that did not have support for setting the default
behavior. Eventually a per user or per database default behavior could be
usefull for the same resons.
Bennefits: - Project managers can easier force programmers to use a specific
database coding style. Fx.: I guess that if the PHP-interface should have a
default value it should be given at the connect time. Programmers could
easily forget to set "autocommit = off" here, thus allowing them self an
eventually unwanted coding style. - Clinents which do not support setting an autocommit default behavior,
can be used by setting the wanted behavior for the database system.
Drawbacks: - ? (Enlighten me)
_________________________________________________________________
Send s�de postkort til s�de mennesker http://www.msn.dk/postkort
