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 по дате отправления: