Re: Vote totals for SET in aborted transaction
От | Hannu Krosing |
---|---|
Тема | Re: Vote totals for SET in aborted transaction |
Дата | |
Msg-id | 1020098478.27494.23.camel@taru.tm.ee обсуждение исходный текст |
Ответ на | Re: Vote totals for SET in aborted transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Vote totals for SET in aborted transaction
|
Список | 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
В списке pgsql-hackers по дате отправления: