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 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
