Tom Lane writes: > I didn't say "transaction specific". I said that if you do a SET inside > a transaction block, and then the transaction is aborted, the effects of > the SET ought to roll back along with everything else you did inside > that transaction block. I'm not seeing what the argument is against > this.
I consider SET variables metadata that are not affected by transactions. I should be able to change my mind about my session preferences in the middle of a transaction, no matter what happens to the data in it. Say somewhere in the middle of a long transaction I think, "I should really be logging this stuff". I turn a knob to do so, and the next command fails. Is the failure logged? In which order does the rollback happen? What if I want to continue logging? If anything were to change I would like to continue accepting SET commands after an error. Of course, I would like to continue accepting any command after an error, but that's a different debate. I guess it's a matter of definition: Do you consider SET variables database state or session metadata? I think some are this and some are that. I'm not sure how to draw the line, but throwing everything from one category into the other isn't my favorite solution. -- Peter Eisentraut [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
