Hiroshi Inoue wrote:
>Tom Lane wrote:
>
>>Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>>
>>>I don't think this is *all* *should be* or *all
>>>or nothing* kind of thing. If a SET variable has
>>>its reason, it would behave in its own right.
>>>
>>Well, we could provide some kind of escape hatch to let the behavior
>>vary from one variable to the next. But can you give any specific
>>examples? Which SET variables should not roll back on error?
>>
>
>It seems veeery dangerous to conclude that SET *should*
>roll back even if there's no *should not* roll back case.
>There could be no *should not* roll back case because
>a user could set the variable as he likes in the next
>transaction.
>
In whihc case, if I'm understanding you correctly Hiroshi-san, the
rollback is moot anyway...
IE
BEGIN transaction_1
...
SET SOMEVAR=SOMETHING
...
COMMIT
(transaction_1 fails and rolls back)
BEGIN transaction_2
...
SET SOMEVAR=SOMETHINGELSE
...
COMMIT
(transaction_2 succeeds)
SOMEVAR, in either case, assuming transaction_2 succeeds, would be
SOMETHINGELSE. If both succeed SOMEVAR is SOMETHINGELSE, if the first
succeeds and the second fails SOMEVAR will be SOMETHING. If neither
succeed SOMEVAR (for this short example) is whatever it was before the
two transactions.
Am I understanding you correctly in that this is the example you were
trying to point out?
>
>
>Hiroshi Inoue
> http://w2422.nsk.ne.jp/~inoue/
>
