From: Craig Ringer <craig@postnewspapers.com.au>
To: Glenn Maynard <glenn@zewt.org>
Cc: pgsql-sql@postgresql.org
Subject: Re: Bit by "commands ignored until end of transaction block" again
Date: Fri, 24 Jul 2009 17:52:26 +0800
Message-ID: <1248429146.1101.193.camel@tillium.localnet> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: craig@postnewspapers.com.au, glenn@zewt.org
Subject: Re: Bit by "commands ignored until end of transaction block" again
In-Reply-To: <1248429146.1101.193.camel@tillium.localnet>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox