Re: plperl and inline functions -- first draft

Joshua Tolley <eggyknap@gmail.com>

From: Joshua Tolley <eggyknap@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alexey Klyukin <alexk@waki.ru>, pgsql-hackers@postgresql.org
Date: 2009-11-18T02:11:00Z
Lists: pgsql-hackers

Attachments

On Tue, Nov 17, 2009 at 06:05:19PM -0500, Andrew Dunstan wrote:
>
>
> Alexey Klyukin wrote:
>>
>> I've noticed that the patch doesn't install current_call_data before calling plperl_call_perl_func, although it saves and restores its previous value. This breaks spi code, which relies on current_call_data->prodesc, i.e.:
>>
>> postgres=# DO $$ $result = spi_exec_query("select 1"); $$ LANGUAGE plperl;
>>   
>
> Yeah, good catch. We need to lift some stuff out of  
> plperl_func_handler(), because this code bypasses that. Not only setting  
> the call_data but also connectin g to the SPI manager and maybe one or  
> two other things.

I kept thinking I had to test SPI, but I guess I hadn't ever done it. The
attached takes care of such stuff, I think.

>> Also, a call to to plperl_call_perl_func should be cast to void to avoid a possible compiler warning (although It doesn't emit one on my system):
>>
>> (void) plperl_call_perl_func(&desc, &fake_fcinfo);
>
> Right.

I don't get the warning either, and didn't realize it could produce one.
Thanks -- that change is also in the attached version.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com