From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Glenn Maynard <glenn(at)zewt(dot)org> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Bit by "commands ignored until end of transaction block" again |
Date: | 2009-07-24 09:52:26 |
Message-ID: | 1248429146.1101.193.camel@tillium.localnet |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-07-24 16:54:31 | Re: Bit by "commands ignored until end of transaction block" again |
Previous Message | Craig Ringer | 2009-07-24 09:43:42 | Re: Bit by "commands ignored until end of transaction block" again |