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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
