This might also permit us to remove one result set (the success/failure one)
and return instead an exception if the transaction is aborted. This is also
more consistent with SQL, if memory serves. That might conflict with returning
the other result sets in the event of abort (though that’s up to
So, thinking on it myself some more, I think if there’s an option that
*doesn’t* require the user to reason about the point at which the read happens
in order to understand how the condition is applied would probably be better.
What do you think of the IF (Boolean expr) ABORT TRANSACTION idea?
Yeah I think that’s intuitive enough. I had been thinking about multiple
condition branches, but was thinking about something closer to
IF select.column=5
UPDATE ... SET ... WHERE key=1;
ELSE IF select.column=6
UPDATE ... SET ... WHERE key=2;
ELSE
UPDATE ... SET ... WHERE key=3;
ENDIF
COMM
