Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
I don't think it's a very good idea to make SET TRANSACTION an alias for
SET LOCAL, because SET TRANSACTION has already got its own meaning in the
SQL spec - it sets transaction modes.
Yeah --- I'm not sure we could even do it without getting shift/reduce
conflicts in bison.
There is some attraction to the idea of keeping SET LOCAL's current
behavior and inventing a third form of SET that has the
lasts-till-end-of-current-main-transaction behavior. However
(1) we'd have to pick some other keyword than TRANSACTION;
(2) I still don't see how to document SET LOCAL's current behavior
without introducing the concept of "subtransaction" into it, and
I think we shouldn't do that.
Basically my perspective on SET LOCAL is that its current behavior is a
bug, and even though it's been that way for a couple major releases now,
it's still something we oughta fix while we are busy whacking that part
of the code around. Florian's example with SET TRANSACTION READ ONLY
proves that it's a bug --- RELEASE is not defined to change any
transaction modes.
Yeah, I think your original proposal was really sound. I would not
expect the current SET LOCAL behaviour in the context of savepoints.
If we really need the current behaviour, we should find a new name for
this lasts-until-savepoint-release-or-transaction-end thingy.
Best Regards
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
