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

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: Per-function GUC settings: trickier than it looked
Дата
Msg-id 46DCC5F6.8090607@phlo.org
обсуждение исходный текст
Ответ на Re: Per-function GUC settings: trickier than it looked  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Per-function GUC settings: trickier than it looked  (Michael Paesold <mpaesold@gmx.at>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Ben Tilly"
Дата:
Сообщение: Re: Hash index todo list item
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: tsearch filenames unlikes special symbols and numbers