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
