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

Florian G. Pflug wrote:
> Tom Lane wrote:
>>> So, to reiterate, my idea is
>>> .) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level.
>>> .) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after 
>>> the
>>>     function exits, even if the function has a matching SET-clause.
>>> .) "SET LOCAL" in pl/pgsql set a new value that is kept if the function
>>>     has no matching SET-clause. If it has one, the value is restored.
>>>     In any case, we emit a warning that "SET LOCAL" is going away.
>>> .) One day, make "SET LOCAL" in pl/pgsql mean "local to the surrounding
>>>     BEGIN/END block". Independent of any SET-clauses the function
>>>     might or might not have.
>>
>> I don't think it's a good idea to change SET LOCAL now and plan on
>> changing it again later ;-).  If we really want BEGIN-block-local
>> SET capability, I'd prefer to think of some new keyword for that.
>> But I'm not convinced it's interesting --- given the proposed behavior
>> of function SET-clauses, attaching a SET to your function seems like
>> it'll cover the need for restoring outer values.
> 
> Hm... could we still have "SET TRANSACTION" as a synonym for "SET LOCAL"?
> That would blend nicely with "SET TRANSACTION ISOLATION LEVEL" and
> "SET TRANSACTION READ ONLY".

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. Although I agree with you that 
variables set with SET LOCAL are also attached to the transaction (by 
definition), I would still rather separate transaction-local GUCs from 
spec-defined transaction modes.

As precedence, they have two separate reference pages already:
http://www.postgresql.org/docs/8.1/interactive/sql-set.html
http://www.postgresql.org/docs/8.1/interactive/sql-set-transaction.html

> [ thinking... ] Hey, wait a moment. Regarding "SET TRANSACTION READ ONLY" -
> This is not strictly speaking a GUC, but still, if we pretend that
> there are no subtransaction, that command should too propage to the
> outermost transaction on release, shouldn't it?
> 
...
> 
> I believe that for consistencies sake, the "set transaction read only" 
> should have propagated to the outermost transaction on "release s1".

Sounds reasonable to me. I understand SAVEPOINT/RELEASE come from the SQL 
standard. So does the SQL standard say anything about this?

Best Regards
Michael Paesold