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