Re: why does plperl cache functions using just a bool for is_trigger
От | Alex Hunsaker |
---|---|
Тема | Re: why does plperl cache functions using just a bool for is_trigger |
Дата | |
Msg-id | AANLkTikTNUONmZqvo5ysdyiWDCFL5zdPwgYng3j7ok6p@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why does plperl cache functions using just a bool for is_trigger (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: why does plperl cache functions using just a bool for
is_trigger
|
Список | pgsql-hackers |
On Sun, Oct 31, 2010 at 12:00, Andrew Dunstan <andrew@dunslane.net> wrote: > On 10/31/2010 11:44 AM, Tom Lane wrote: >> Good catch, patch reverted (and regression test added). > > Well, I guess that answers the question of why we needed it, which nobody > could answer before. I'm not sure I exactly understand what's going on here, > though - I guess I need to look at it closer. At least I think we need a > code comment on why the trigger flag is needed as part of the hash key. The stack trace is: #0 0x0000000000000000 in ?? () #1 0x00000000006c18e9 in InputFunctionCall (flinfo=0x2a039a0, str=0x0, typioparam=0, typmod=-1) #2 0x00007ff6d2bdf950 in plperl_func_handler (fcinfo=0x7fff4743bec0) at plperl.c:1729 which happens because prodesc->result_in_func.fn_addr (flinfo) is NULL. That happens because when we are a trigger we don't setup input/output conversion. And with the change we get the same proc_desc for triggers and non triggers, so if the trigger function gets called first, any call to the direct function will use the same proc_desc with the wrong input/out conversion. There is a check so that trigger functions can not be called as plain functions, but it only gets called when we do not have an entry in plperl_proc_hash. I think just moving that up, something the like the attached should be enough. Thoughts?
Вложения
В списке pgsql-hackers по дате отправления: