> > 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.
I am with Tom on this one. (Nice to see he is now arguing on my side.)
Making different variables behave differently is clearly going to
confuse users. The argument that we should allow SET to work when the
transaction is in ABORT state seems very wierd to me because we ignore
every other command in that state. I think reversing out any SET's done
in an aborted transaction is the clear way to go. If users want their
SET to not be affected by the transaction abort, they should put their
SET's outside a transaction; seems pretty clear to me.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026