Re: Vote totals for SET in aborted transaction - Mailing list pgsql-hackers
From | John Ingram |
---|---|
Subject | Re: Vote totals for SET in aborted transaction |
Date | |
Msg-id | 009601c1eff2$8d9411e0$b642a6d0@oemcomputer Whole thread Raw |
In response to | Re: Vote totals for SET in aborted transaction ("Marc G. Fournier" <scrappy@hub.org>) |
List | pgsql-hackers |
----- Original Message ----- From: "Marc G. Fournier" <scrappy@hub.org> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: "Hannu Krosing" <hannu@tm.ee>; "Scott Marlowe" <scott.marlowe@ihs.com>; "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Monday, April 29, 2002 2:10 PM Subject: Re: [HACKERS] Vote totals for SET in aborted transaction LOCAL <NESTED TRANSACTION NAME> SET .... ? >> > > What happens inside of a nested transaction, assuming we do have those > evenually ... ? > > On Mon, 29 Apr 2002, Tom Lane wrote: > > > Hannu Krosing <hannu@tm.ee> writes: > > > 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. > > > > This makes my head hurt. If I do > > > > SET foo TO bar; > > begin; > > SET SET TO GLOBAL; > > SET foo TO baz; > > SET SET TO LOCAL TO TRANSACTION; > > end; > > > > (assume no errors) what is the post-transaction state of foo? > > > > What about this case? > > > > SET foo TO bar; > > begin; > > SET SET TO GLOBAL; > > SET foo TO baz; > > SET SET TO LOCAL TO TRANSACTION; > > SET foo TO quux; > > end; > > > > Of course this last case also exists with my idea of a LOCAL SET > > command, > > > > SET foo TO bar; > > begin; > > SET foo TO baz; > > LOCAL SET foo TO quux; > > -- presumably SHOW foo will show quux here > > end; > > -- does SHOW foo now show bar, or baz? > > > > Arguably you'd need to keep track of up to three values of a SET > > variable to make this work --- the permanent (pre-transaction) value, > > to roll back to if error; the SET value, which will become permanent > > if we commit; and the LOCAL SET value, which may mask the pending > > permanent value. This seems needlessly complex though. Could we get > > away with treating the above case as an error? > > > > In any case I find a LOCAL SET command more reasonable than making > > SET's effects depend on the value of a SETtable setting. There is > > circular logic there. If I do > > > > begin; > > SET SET TO LOCAL TO TRANSACTION; > > end; > > > > what is the post-transaction behavior of SET? And if you say LOCAL, > > how do you justify it? Why wouldn't the effects of this SET be local? > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
pgsql-hackers by date: