Subject: Re: Bit by "commands ignored until end of transaction block"
  again
From: Craig Ringer <craig@postnewspapers.com.au>
To: Glenn Maynard <glenn@zewt.org>
Cc: pgsql-sql@postgresql.org
In-Reply-To: <bd36f99e0907230039l29b66027ibf51ae2c715a44b6@mail.gmail.com>
References: <bd36f99e0907222158k6b4b3a0al65766c0d9c4906cf@mail.gmail.com>
	<4A67F5B6.4080409@archonet.com>
	<bd36f99e0907222304x38cfa50bkeba19f7c9b2694@mail.gmail.com>
	<4A680603.9010707@archonet.com>
	<bd36f99e0907230039l29b66027ibf51ae2c715a44b6@mail.gmail.com>
Content-Type: text/plain
Date: Fri, 24 Jul 2009 17:52:26 +0800
Message-Id: <1248429146.1101.193.camel@tillium.localnet>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2009-07-23 at 03:39 -0400, Glenn Maynard wrote:

> I'm writing a Python library call.  It has no idea whether the caller
> happens to be inside a transaction already, and I don't want to
> specify something like "always run this inside a transaction".
> (Callers are equally likely to want to do either, and it's bad API to
> force them to start a transaction--the fact that I'm using the
> database at al should be transparent.)

Personally, I'd think about moving the function into the database, using
PL/PgSQL or even PL/PythonU if you have to.

Why should DB use be transparent when you're modifying the DB? In one
case you immediately make a change. In another case, you schedule a
change to be applied if/when the current transaction commits, so the
change may or may not occur at some point in the future. That is, IMO, a
big difference.

Most applications with this sort of thing will have app-level
transaction APIs that contain and manage the DB-level ones anyway.

> RELEASE SAVEPOINT would only COMMIT the transaction *if* the savepoint
> that it's releasing started it.

So, what you're really asking for boils down to nestable transactions?

-- 
Craig Ringer