Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> I was trying to say that _IF_ one ever needs to "SET" stuff that can't be
> rolled back then it may be better to use some other keyword for that feature.
> I'm actually for #1 SET being rolled back and to not have any "Oracle
> behaviour" settings at all. Anything that can't be rolled back shouldn't
> use SET.
Ah, I understand. Okay, I see a perfect candidate for the other syntax:
ALTER SESSION SET ...
(or whatever the heck that Oracle syntax was). But I'm still looking
for a case of a variable where we actually want this behavior.
The Ingres examples Lee cited were interesting --- but they all appear
to me to correspond to system-wide settings, which we do not allow SET
to modify anyway. (To change system-wide settings, you have to change
postgresql.conf, and then SIGHUP or restart the postmaster. This
ensures all the backends get the word. And indeed this behavior is
outside transactional control.)
I'm still looking for an example of something that is (a) reasonable
to set on a per-backend basis, and (b) not reasonable to roll back
if it's set in a transaction that fails.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
