Craig Ringer wrote:
On Sun, 2009-07-26 at 19:15 -0400, Science wrote:
FWIW, the way the Rails ORM ActiveRecord (another fairly damaged ORM)
handles this is by allowing you to open any number of transaction
blocks, but only the outer transaction block commits (in Pg):
Property.transaction { #
On Sun, 2009-07-26 at 19:15 -0400, Science wrote:
> FWIW, the way the Rails ORM ActiveRecord (another fairly damaged ORM)
> handles this is by allowing you to open any number of transaction
> blocks, but only the outer transaction block commits (in Pg):
>
> Property.transaction { # SQL => 'BEGI
Date: Thu, 23 Jul 2009 09:06:50 +0100
From: Richard Huxton
To: Glenn Maynard
Cc: pgsql-sql@postgresql.org
Subject: Re: Bit by "commands ignored until end of transaction block"
again
Message-ID: <4a681a1a.1090...@archonet.com>
Glenn Maynard wrote:
On Thu, Jul 23, 2009 at 2:41 AM, Richar
> The above situation only arises if you run in autocommit mode which is the
> default for psql (which I have *never* understood).
This is the short answer, in practice--assume that either a
transaction is started or will be started by the SAVEPOINT command,
and that if a COMMIT is needed (as a r
On Fri, Jul 24, 2009 at 12:54:31PM -0400, Alvaro Herrera wrote:
> Joshua Tolley escribió:
>
> > Have you tried this? I expect if you give it a shot, you'll find you don't
> > actually have this problem. Really, everything is always in a transaction.
> > If
> > you haven't explicitly opened one, P
Joshua Tolley escribió:
> Have you tried this? I expect if you give it a shot, you'll find you don't
> actually have this problem. Really, everything is always in a transaction. If
> you haven't explicitly opened one, PostgreSQL opens one for you before each
> statement, and issues a COMMIT afterw
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 t
On Thu, 2009-07-23 at 17:06 +1000, Chris wrote:
> Joshua Tolley wrote:
> > On Thu, Jul 23, 2009 at 02:04:53AM -0400, Glenn Maynard wrote:
> >> On Thu, Jul 23, 2009 at 1:31 AM, Richard Huxton wrote:
> - Let me use SAVEPOINT outside of a transaction,
> >>> You are never outside a transaction. A
On Thursday 23 July 2009 12:39:23 am Glenn Maynard wrote:
>
> The ORM on a whole is decent, but there are isolated areas where it's
> very braindamaged--this is one of them. They have a stable-release
> API-compatibility policy, which I think just gets them stuck with some
> really bad decisions
* Glenn Maynard (gl...@zewt.org) wrote:
> > The ORM can't control transactions, can't call functions or can't set
> > savepoints?
>
> It can't write the necessary SQL to say "insert this unless it already
> exists", namely:
If it can't cleanly handle failure cases like this one, then I think
your
Glenn Maynard wrote:
On Thu, Jul 23, 2009 at 2:41 AM, Richard Huxton wrote:
Ah [cue light-bulb effect], I think I understand. Your function isn't in the
database is it? Surely your application knows if it's issuing BEGIN..COMMIT?
I'm writing a Python library call. It has no idea whether the c
On Thu, Jul 23, 2009 at 2:41 AM, Richard Huxton wrote:
> Ah [cue light-bulb effect], I think I understand. Your function isn't in the
> database is it? Surely your application knows if it's issuing BEGIN..COMMIT?
I'm writing a Python library call. It has no idea whether the caller
happens to be i
Chris, 23.07.2009 09:06:
psql -d dbname
..
# select now();
now
---
2009-07-23 17:04:21.406424+10
(1 row)
Time: 2.434 ms
(csm...@[local]:5432) 17:04:21 [test]
# savepoint xyz;
ERROR: SAVEPOINT can only be used in transaction blocks
(csm...@[local]:5432)
Joshua Tolley wrote:
On Thu, Jul 23, 2009 at 02:04:53AM -0400, Glenn Maynard wrote:
On Thu, Jul 23, 2009 at 1:31 AM, Richard Huxton wrote:
- Let me use SAVEPOINT outside of a transaction,
You are never outside a transaction. All queries are executed within a
transaction.
"Transaction block",
On Thu, Jul 23, 2009 at 02:04:53AM -0400, Glenn Maynard wrote:
> On Thu, Jul 23, 2009 at 1:31 AM, Richard Huxton wrote:
> >> - Let me use SAVEPOINT outside of a transaction,
> >
> > You are never outside a transaction. All queries are executed within a
> > transaction.
>
> "Transaction block", th
Glenn Maynard wrote:
On Thu, Jul 23, 2009 at 1:31 AM, Richard Huxton wrote:
- Let me use SAVEPOINT outside of a transaction,
You are never outside a transaction. All queries are executed within a
transaction.
"Transaction block", then, if you insist.
I think this is the root of your proble
On Thu, Jul 23, 2009 at 1:31 AM, Richard Huxton wrote:
>> - Let me use SAVEPOINT outside of a transaction,
>
> You are never outside a transaction. All queries are executed within a
> transaction.
"Transaction block", then, if you insist.
> I think this is the root of your problem - all queries
Glenn Maynard wrote:
Postgres kills a transaction when an error happens. This is a pain;
it assumes that all SQL errors are unexpected and fatal to the
transaction.
There's a very simple case where it's not: UNIQUE checks.
Ah, it's usually "syntax errors" wrt interactive sessions.
> I'm
ge
Postgres kills a transaction when an error happens. This is a pain;
it assumes that all SQL errors are unexpected and fatal to the
transaction.
There's a very simple case where it's not: UNIQUE checks. I'm
generating a cache, with a simple flow:
- Search for the cache key; if it exists, return
19 matches
Mail list logo
