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

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".

[ 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?

This is what happens currently (CVS HEAD with at least your initial
function-SET-clause patch already in)
regression=# begin ;
BEGIN
regression=# savepoint s1 ;
SAVEPOINT
regression=# set transaction read only ;
SET
regression=# release s1 ;
RELEASE
regression=# create table test (id int) ;
CREATE TABLE
regression=# commit ;
COMMIT

compared to:
regression=# begin ;
BEGIN
regression=# set transaction read only ;
SET
regression=# create table test (id int) ;
ERROR: transaction is read-only

I believe that for consistencies sake, the "set transaction read only" should
have propagated to the outermost transaction on "release s1".

greetings, Florian Pflug