Re: Vote on SET in aborted transaction

Hiroshi Inoue wrote:

>Michael Loftis wrote:
>
>>Hiroshi Inoue wrote:
>>
>>>What's wrong with it ? The insert command after *rollback*
>>>would fail. It seems the right thing to me. Otherwise
>>>the insert command would try to append the data of the
>>>table t1 to itself. The insert command is for copying
>>>schema1.t1 to foo.t1 in case the previous create schema
>>>command suceeded.
>>>
>>Exactly, in this example shows exactly why SETs should be part of the
>>transaction and roll back. Heck the insert may not even fail after all
>>anyway and insert into the wrong schema. If the insert depends on the
>>schema create succeeding it should be in the same transaction. (IE it
>>would get rolled back or not happen at all)
>>
>
>Where's the restriction that all objects in a schema
>must be created in an transaction ? Each user has his
>reason and would need various kind of command call sequence.
>What I've mainly insisted is what to do with errors is
>users' responsibilty but I've never seen the agreement
>for it. So my current understanding is you all
>are thinking what to do with errors is system's
>responsibilty. Then no matter how users call commands
>the dbms must behave appropriately, mustn't it ?
>
IMHO as a user and developer it's more important to behave consistently.
A rollback should cause everything inside of a transaciton block to
rollback. If you need to keep something then it should either be done in
it's own transaction, or outside of an explicit transaction entirely.

There is no restriction. The system is handling an error in the way
instructed by the user either ROLLBACK or COMMIT. If you COMMIT with
errors, it's your problem. But if you askt he system to ROLLBACK it's
the users expectation that the DBMS will ROLLBACK. Not ROLLBACK this and
that, but leave another thing alone. You say BEGIN ... COMMIT you expect
a COMMIT, you say BEGIN ... ROLLBACK you expect a ROLLBACK. You say
BEGIN ... END the DBMS should 'do the right thing' (IE COMMIT if
successfull, ROLLBACK if not). Thats the behaviour I'd expect from ANY
transactional system.

The user will (and rightfully so) expect a ROLLBACK to do just that for
everything. Yes this will break the way things work currently, but on
the whole, and going forward, it makes the system consistent. Right now
we roll back SELECTs, CREATEs, UPDATEs, etc., but not SETs (or atleast
from what I can tell that's what we do.)

I understand what you're saying Hiroshi-san, but really, it's a very
weak reason. If you (as a programmer/developer) do something like in
your earlier example (perform an insert after ROLLBACK) then you know an
error occurred, and it's your own fault for inserting into the wrong
table outside of the transaction.