Re: Vote totals for SET in aborted transaction

I've been thinking this over and over, and it seems to me, that the way 
SETS in transactions SHOULD work is that they are all rolled back, period, 
whether the transaction successfully completes OR NOT.

Transactions ensure that either all or none of the DATA in the database is 
changed.  That nature is good.  But does it make sense to apply 
transactional mechanics to SETtings?  I don't think it does.

SETtings aren't data operators, so they don't need to be rolled back / 
committed so to speak.  Their purpose is to affect the way things like the 
database works in a more overreaching sense, not the data underneath it.

For this reason, I propose that a transaction should "inherit" its 
environment, and that all changes EXCEPT for those affecting tuples should 
be rolled back after completion, leaving the environment the way we found 
it.  If you need the environment changed, do it OUTSIDE the transaction.

I would argue that the rollback on failure / don't rollback on completion 
is actually the worse possible way to handle this, because, again, this 
isn't about data, it's about environment.  And I don't think things inside 
a transaction should be mucking with the environment around them when 
they're done.

But that's just my opinion, I could be wrong.  Scott Marlowe