I just got this explanation for the autocommit setting. Maybe we should add
thsi to the docs.

----- Forwarded message from Robert Hufsky <Robert.Hufsky@ser.at> -----

From: "Robert Hufsky" <Robert.Hufsky@ser.at>
To: "Michael Meskes" <meskes@debian.org>
Subject: autocommit in ecpg
Date: Fri, 18 Jan 2002 08:21:17 +0100

[...]

Transaction Control and Autocommit
An application can be operating in "autocommit on" or "autocommit off" mode.
The mode can be selected by issuing

exec sql set autocommit to on; or
exec sql set autocommit to off;

Autocommit Off

In this mode, no sql statement is ever committed unless explicitly stated by

exec sql commit;

>From the beginning of a database session an implicit transaction is open.
Each SQL statement that is issued is part of the transaction. The
transaction is closed and work is committed by exec sql commit;.

Immediately after the exec sql commit; statement a new transaction is opened
and the same rules apply.

Note that an exec sql begin; statement is not applicable in "autocommit off"
mode.

Autocommit On

In this mode, each statement is automatically committed. This can be
convinient but it also can lead to performance problems as each implicit
commit may cause a disk write operation.

Even in "autocommit on" mode, multi-statememt transactions can be achieved
by placing multiple SQL statements between

exec sql begin;
  and
exec sql commit;

[...]
----- End forwarded message -----

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Fri, 18 Jan 2002 16:54:09 +0100
Michael Meskes <meskes@postgresql.org>
[Robert.Hufsky@ser.at: autocommit in ecpg]
OK, I have added this information to the ecpg and ref/ecpg manual pages
as appropriate.  Let me know if I should add anything else.  I also
removed a comment from the bottom of ref/sgml that didn't make any sense.

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

Michael Meskes wrote:
> I just got this explanation for the autocommit setting. Maybe we should add
> thsi to the docs.
> 
> ----- Forwarded message from Robert Hufsky <Robert.Hufsky@ser.at> -----
> 
> From: "Robert Hufsky" <Robert.Hufsky@ser.at>
> To: "Michael Meskes" <meskes@debian.org>
> Subject: autocommit in ecpg
> Date: Fri, 18 Jan 2002 08:21:17 +0100
> 
> [...]
> 
> Transaction Control and Autocommit
> An application can be operating in "autocommit on" or "autocommit off" mode.
> The mode can be selected by issuing
> 
> exec sql set autocommit to on; or
> exec sql set autocommit to off;
> 
> Autocommit Off
> 
> In this mode, no sql statement is ever committed unless explicitly stated by
> 
> exec sql commit;
> 
> >From the beginning of a database session an implicit transaction is open.
> Each SQL statement that is issued is part of the transaction. The
> transaction is closed and work is committed by exec sql commit;.
> 
> Immediately after the exec sql commit; statement a new transaction is opened
> and the same rules apply.
> 
> Note that an exec sql begin; statement is not applicable in "autocommit off"
> mode.
> 
> Autocommit On
> 
> In this mode, each statement is automatically committed. This can be
> convinient but it also can lead to performance problems as each implicit
> commit may cause a disk write operation.
> 
> Even in "autocommit on" mode, multi-statememt transactions can be achieved
> by placing multiple SQL statements between
> 
> exec sql begin;
>   and
> exec sql commit;
> 
> [...]
> ----- End forwarded message -----
> 
> Michael
> -- 
> Michael Meskes
> Michael@Fam-Meskes.De
> Go SF 49ers! Go Rhein Fire!
> Use Debian GNU/Linux! Use PostgreSQL!
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Index: doc/src/sgml/ecpg.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v
retrieving revision 1.33
diff -c -r1.33 ecpg.sgml
*** doc/src/sgml/ecpg.sgml	2002/01/07 02:29:11	1.33
--- doc/src/sgml/ecpg.sgml	2002/01/18 20:30:13
***************
*** 1053,1066 ****
      </para>
  
      <para>
!      All <acronym>SQL</acronym> statements are performed in one
!      transaction unless you issue a commit transaction. To accomplish
!      this auto-transaction behavior, the first statement and the first
!      statement after a commit or rollback always begins a new transaction. To
!      disable this feature, use the <option>-t</option> command-line
!      option.
      </para>
- 
     </sect2>
    </sect1>
   </chapter>
--- 1053,1068 ----
      </para>
  
      <para>
!      In the default mode, queries are committed only when <command>exec
!      sql commit</command> is issued. <application>Ecpg</application>
!      also supports auto-commit of transactions via the
!      <option>-t</option> command-line option or via the <literal>exec
!      sql set autocommit to on</literal> statement. In
!      <literal>autocommit<literal> mode, each query is automatically
!      committed unless it is inside an explicit transaction block. This
!      mode can be explicitly turned off using <literal>exec sql set
!      autocommit to off</literal>.
      </para>
     </sect2>
    </sect1>
   </chapter>
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.85
diff -c -r1.85 libpq.sgml
*** doc/src/sgml/libpq.sgml	2002/01/07 02:29:12	1.85
--- doc/src/sgml/libpq.sgml	2002/01/18 20:30:19
***************
*** 2109,2118 ****
  <para>
  <filename>libpq</filename> is thread-safe as of
  <productname>PostgreSQL</productname> 7.0, so long as no two threads
! attempt to manipulate the same <structname>PGconn</> object at the same time.  In particular,
! you cannot issue concurrent queries from different threads through the same
! connection object.  (If you need to run concurrent queries, start up multiple
! connections.)
  </para>
  
  <para>
--- 2109,2125 ----
  <para>
  <filename>libpq</filename> is thread-safe as of
  <productname>PostgreSQL</productname> 7.0, so long as no two threads
! attempt to manipulate the same <structname>PGconn</> object at the same
! time. In particular, you cannot issue concurrent queries from different
! threads through the same connection object. (If you need to run
! concurrent queries, start up multiple connections.)
! </para>
! <para>
! However, <filename>libpq</filename> clients using the
! <literal>crypt</literal> encryption method rely on the
! <literal>crypt()</literal> operating system function, which often is not
! thread-safe. It is better to use <literal>MD5</literal> encryption,
! which is guarantted to be thread-safe on all platforms.
  </para>
  
  <para>
Index: doc/src/sgml/ref/ecpg-ref.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v
retrieving revision 1.16
diff -c -r1.16 ecpg-ref.sgml
*** doc/src/sgml/ref/ecpg-ref.sgml	2002/01/06 18:12:00	1.16
--- doc/src/sgml/ref/ecpg-ref.sgml	2002/01/18 20:30:20
***************
*** 57,63 ****
        <term>-t</term>
        <listitem>
         <para>
! 	Turn on auto-commit of transactions.
         </para>
        </listitem>
       </varlistentry>
--- 57,66 ----
        <term>-t</term>
        <listitem>
         <para>
! 	Turn on auto-commit of transactions. In this mode, each query is
! 	automatically committed unless it is inside an explicit
! 	transaction block. In the default mode, queries are committed
! 	only when <command>exec sql commit</command> is issued.
         </para>
        </listitem>
       </varlistentry>
***************
*** 403,434 ****
     See the <filename>TODO</filename> file in the source for some more
     missing features.
    </para>
- 
- <!--
- .SH FILES
- .PD 0
- .TP
- .B /usr/src/pgsql/postgresql-${ver}/src/interfaces...
-  ./ecpg/include.......source for \fIecpg\fP header files.
-  ./ecpg/lib...........source for \fIecpg\fP libraries.
-  ./ecpg/preproc.......source for \fIecpg\fP header files.
-  ./ecpg/test..........source for \fIecpg\fP libraries.
-  (test contains examples of syntax for ecpg SQL-C.)
- .PD
- .TP
- .B /usr/local/pgsql/bin 
- \fIPostgreSQL\fP binaries including \fIecpg\fP.
- .PD
- .TP
- .B /usr/local/pgsql/include 
- \fIPostgreSQL\fP headers including \fIecpglib.h\fP \fIecpgtype.h\fP 
- and \fIsqlca.h\fP.
- .PD
- .TP
- .B /usr/local/pgsql/lib 
- \fIPostgreSQL\fP libraries including \fIlibecpg.a\fP and 
- \fIlibecpg.so\fP.
- -->
  
   </refsect1>
  </refentry>
--- 406,411 ----
Fri, 18 Jan 2002 15:32:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [Robert.Hufsky@ser.at: autocommit in ecpg]