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

[ 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 ;
regression=# savepoint s1 ;
regression=# set transaction read only ;
regression=# release s1 ;
regression=# create table test (id int) ;
regression=# commit ;

compared to:
regression=# begin ;
regression=# set transaction read only ;
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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to