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.