Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > 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.)
>
> I vote against you. If a variable is local to the session, you
> can change it as you like without bothering any other user(session).
> Automatic resetting of the varibales is rather confusing to me.
I don't see how this relates to other users. All SET commands that can
be changed in psql are per backend, as far as I remember.
-- 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
