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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
