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

Re: Vote totals for SET in aborted transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vote totals for SET in aborted transaction
Date: 2002-04-29 15:30:35
Message-ID: 23988.1020094235@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.)

It might well be useful to have some kind of LOCAL SET command that
behaves the way you describe (effects good only for current transaction
block), but I don't think it follows that that should be the only
behavior available.

What would you expect if LOCAL SET were followed by SET on the same
variable in the same transaction?  Presumably the LOCAL SET would then
be nullified; or is this an error condition?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-04-29 15:33:36
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Thomas LockhartDate: 2002-04-29 15:29:56
Subject: Re: Vote totals for SET in aborted transaction

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