Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id VAA98668
	for <pgsql-interfaces@postgreSQL.org>;
	Thu, 8 Jul 1999 21:21:34 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA01318;
	Thu, 8 Jul 1999 21:20:58 -0400 (EDT)
To: George Young <gry@ll.mit.edu>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] transactions in libpq++ require new connection? 
In-reply-to: Your message of Thu, 8 Jul 1999 15:55:59 -0400 (EDT)
	<199907081955.PAA21607@ll.mit.edu>
Date: Thu, 08 Jul 1999 21:20:58 -0400
Message-ID: <1316.931483258@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

George Young <gry@ll.mit.edu> writes:
> Currently, the PgTransaction class only has a public constructor which
> opens a new connection to the DB, and closes it on commit.

Ugh.  I agree that's pretty awful.

> I know I can roll my own by just Exec("begin"), etc, but having the
> transaction *committed* (not conn closed) in the destructor would be very
> handy.
> Also, there's no rollback member...

Actually, I think the cleanest design would be to have a commit() member
function.  If the object is destroyed without having committed, the
default behavior ought to be to abort (rollback), not commit.  The
reason I think this is that if you imagine a PgTransaction object that
is local to a function, and the function is exited by an exception,
you probably want abort to happen rather than commit.

There might be some cases where you'd rather it worked the other way
around --- if so, we could have a constructor option to set the default
behavior at destruct time.  But I think defaulting to abort would be the
safest behavior for a program that uses exceptions.

			regards, tom lane