Peter Eisentraut <peter_e@gmx.net> writes:
> I consider SET variables metadata that are not affected by transactions.
Why? Again, the fact that historically they've not acted that way isn't
sufficient reason for me.
> 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?
Hm. That's a slightly more interesting example than before ... but it
comes close to arguing that logging should be under transaction control.
Surely you'd not argue that a failed transaction should erase all its
entries from the postmaster log? Why would you expect changes in log
levels to be retroactive?
> 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.
You seem to be suggesting that we should make a variable-by-variable
decision about whether SET variables roll back on ABORT or not. I think
that way madness lies; we could spend forever debating which vars are
which, and then who will remember without consulting the documentation?
I feel we should just do it. Yeah, there might be some corner cases
where it's not the ideal behavior; but you haven't convinced me that
there are more cases where it's bad than where it's good. You sure
haven't convinced me that it's worth making SET's behavior
nigh-unpredictable-without-a-manual, which is what per-variable behavior
would be.
regards, tom lane
