Date: Mon, 18 Nov 2002 10:15:55 +0000
From: Tim Bunce <Tim.Bunce@pobox.com>
To: David Wheeler <david@wheeler.net>
Cc: dbi-dev@perl.org, pgsql-interfaces@postgresql.org
Subject: Re: DBD::PostgreSQL
Message-ID: <20021118101554.GU1408@dansat.data-plan.com>
References: <E5AF995E-FAA1-11D6-93B3-0003931A964A@wheeler.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E5AF995E-FAA1-11D6-93B3-0003931A964A@wheeler.net>
User-Agent: Mutt/1.4i

On Sun, Nov 17, 2002 at 07:00:30PM -0800, David Wheeler wrote:
> 
> * In DBD::Pg's dbdimp.c, the dbd_db_commit() function attempts a 
> commit, and if it's successful, it then starts another transaction. Is 
> this the proper behavior? The other DBDs I looked at don't appear to 
> BEGIN a new transaction in the dbd_db_commit() function.

Many databases, like Oracle, automatically start a transaction at
the server as soon as it's needed. The application doesn't have to
do it explicitly. (DBD::Informix is probably a good example of a
driver that needs to start transactions explicitly.)

> * A similar question applies to dbd_db_rollback(). It does a rollback, 
> and then BEGINs a new transaction. Should it be starting another 
> transaction there?

Drivers are free to defer starting a new transaction until it's needed.
Or they can start one right away, but that may cause problems on
the server if there are many 'idle transactions'. (Also beware that
some databases don't allow certain statements, like some 'alter
session ...', to be issued while a transaction is active. If that
applies to Pg then you may have a problem.)

> * How is DBI's begin_work() method intended to influence commits and 
> rollbacks?