Oh, I like ... kinda like in perl where if you set a variable 'my' inside of conditional, it no longer exists outside of that conditional ...
I do like this ... On Mon, 29 Apr 2002, Scott Marlowe wrote: > 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] > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
