Re: Vote totals for SET in aborted transaction
Hannu Krosing <hannu@tm.ee>
From: Hannu Krosing <hannu@tm.ee>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Scott Marlowe <scott.marlowe@ihs.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2002-04-29T16:41:17Z
Lists: pgsql-hackers
On Mon, 2002-04-29 at 17:30, Tom Lane wrote: > Scott Marlowe <scott.marlowe@ihs.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? Perhaps we could do SET SET TO LOCAL TO TRANSACTION; Which would affect itself and all subsequent SET commands up to SET SET TO GLOBAL; or end of transaction. ------------- SET SET TO GLOBAL could also be written as SET SET TO NOT LOCAL TO TRANSACTION; to comply with genral verbosity of SQL ;) ---------- Hannu