Tom Lane wrote:
> Michael Paesold <mpaesold@gmx.at> 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
