Michael Loftis wrote:
>
> 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)
Probably you are misunderstanding my point.
I don't think that SOMEVAR *should* be put back
on failure.
Users must know what value would be set to the
SOMEVAR after an error. In some cases it must
be put back, in some cases the current value
is OK, in other cases new SOMEVAR is needed.
Basically it's a user's resposibilty to set
the value.
regards,
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/
