Re: Per-function GUC settings: trickier than it looked

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