Re: Plperl trigger variables no longer global

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: Plperl trigger variables no longer global
Дата
Msg-id BANLkTinU_PXwUid1iM7zR081rwb13gqW6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Plperl trigger variables no longer global  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Plperl trigger variables no longer global
Список pgsql-bugs
On Thu, May 5, 2011 at 06:51, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> Excerpts from Alex Hunsaker's message of mié may 04 23:53:34 -0300 2011:
>
>> After playing with it a bit more I see 2 clear options:
>> 1) make $_TD global like %_SHARED. This should not cause any problems
>> as we make $_TD private via local() before each trigger call. Also pre
>> 9.1 non trigger functions could still access and check the definedness
>> of $_TD so if someone was relying on that (for whatever unknown
>> reason) that will work again.
>
> This is strange.  Are you saying that there's no decent way to make a
> variable global in C code?

Im sure we could... I don't see any reason to do it in C. (performance
or otherwise)

In other news I found another bug with this-- it was trying to
local($_TD) by using SAVESPTR() when it seems it really should be
using save_item(). Currently its not really localizing $_TD, which at
the very least means recursive triggers might modify the callers $_TD.
Ugh.

Fixed in the attached plus added regression tests for both issues (use
strict; && Global symbol "$_TD" requires explicit package name, test
recursive trigger calls). Although Ill admit, given the point we are
in the release I could see a revert also being justified.

Greg, big thanks for testing! keep it up! :)

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6008: Can't contact Tom Lane :)
Следующее
От: "Nestor"
Дата:
Сообщение: BUG #6009: Duvida