Re: Postgres config file: autocommit = off

>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