From: | Bradley McLean <brad(at)bradm(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vote on SET in aborted transaction |
Date: | 2002-04-23 16:43:03 |
Message-ID: | 20020423124303.A830@nia.bradm.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Bruce Momjian (pgman(at)candle(dot)pha(dot)pa(dot)us) [020423 12:30]:
>
> 1 - All SETs are rolled back in aborted transaction
> 2 - SETs are ignored after transaction abort
> 3 - All SETs are honored in aborted transaction
> ? - Have SETs vary in behavior depending on variable
>
> Our current behavior is 2.
>
> Please vote and I will tally the results.
#2, no change in behavior.
But I base that on the assumption that #1 or #3 involve serious amounts
of work, and don't see the big benefit.
I liked the line of thought that was distinguishing between in-band
(rolled back) and out-of-band (honored) SETs, although I don't think
any acceptable syntax was arrived at, and I don't have a suggestion.
If this were solved, I'd vote for '?'.
Hmm. Maybe I do have a suggestion: SET [TRANSACTIONAL] ...
But it might not be very practical.
-Brad
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-23 16:46:43 | Re: Vote on SET in aborted transaction |
Previous Message | Bruce Momjian | 2002-04-23 16:42:28 | Re: Index Scans become Seq Scans after VACUUM ANALYSE |