>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


Mon, 02 Jun 2003 21:34:41 +0200
"Rasmus Resen Amossen" <rresena@hotmail.com>
Re: Postgres config file: autocommit = off

I agree with you, but as outvoted by the group --- can someone give the
the client-side argument for him.  I know it, but my heart isn't in it. :-)

---------------------------------------------------------------------------

Rasmus Resen Amossen wrote:
> >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
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 2 Jun 2003 15:48:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Postgres config file: autocommit = off