...
> Please note that even in those other databases, if one replaces the
> COMMIT with ROLLBACK in the above scenario, the effects of the INSERT
> *will* roll back. Transpose this into current Postgres, and replace
> INSERT with SET, and the effects do *not* roll back. How is that a
> good idea?
Well, as you should have concluded by now, "good" is not the same for
everyone ;)
Frankly, I've been happy with the current SET behavior, but would also
be willing to consider most of the alternatives which have been
suggested, including ones you have dismissed out of hand. Constraints
which seem to have been imposed include:
1) All commands starting with "SET" must have the same transactional
semantics. I'll agree that it might be nice for consistancy, but imho is
not absolutely required.
2) No commands which could be expected to start with "SET" will start
with some other keyword. If we do have "set class" commands which have
different transactional semantics, then we could explore alternative
syntax for specifying each category.
3) "SET" commands must respect transactions. I'm happy with the idea
that these commands are out of band and take effect immediately. And if
they take effect even in the middle of a failing/failed transaction,
that is OK too. The surrounding code would have reset the values anyway,
if necessary.
I do have a concern about how to implement some of the SET commands if
we *do* respect transactional semantics. For example, SET TIME ZONE
saves the current value of an environment variable (if available), and
would need *at least* a "before transaction" and "after transaction
started" pair of values. How would we propagate SET variables to
transaction-specific structures, clearing or resetting them later? Right
now these variables are pretty independent and can be accessed through
global storage; having transactional semantics means that the
interdependencies between different variable types in the SET handlers
may increase.
- Thomas
