Skip site navigation (1) Skip section navigation (2)

Re: Vote totals for SET in aborted transaction

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-29 16:32:12
Message-ID: 20020429133001.Y15173-100000@mail1.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, 29 Apr 2002, Tom Lane wrote:

> Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com> writes:
> > I've been thinking this over and over, and it seems to me, that the way
> > SETS in transactions SHOULD work is that they are all rolled back, period,
> > whether the transaction successfully completes OR NOT.
>
> This would make it impossible for SET to have any persistent effect
> at all.  (Every SQL command is inside a transaction --- an
> implicitly-established one if necesary, but there is one.)

Why?  What I think Scott is proposing is that on COMMIT *or* ABORT, all
SETs since the BEGIN are reversed ... hrmmm ... that didnt' sound right
either ... is there no way of distiguishing between an IMPLICT transcation
vs an EXPLICIT one?

INSERT ...

vs

BEGIN
INSERT ...
COMMIT

?



In response to

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-04-29 16:38:41
Subject: Re: clarification of timestamp
Previous:From: Thomas LockhartDate: 2002-04-29 16:30:32
Subject: Re: Vote totals for SET in aborted transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group