Re: plperl and inline functions -- first draft - Mailing list pgsql-hackers

From Joshua Tolley
Subject Re: plperl and inline functions -- first draft
Date
Msg-id 20091118021100.GB3803@eddie
Whole thread Raw
In response to Re: plperl and inline functions -- first draft  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: plperl and inline functions -- first draft
List pgsql-hackers
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
savesand 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'temit 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

Attachment

pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: Very bad FTS performance with the Polish config
Next
From: Euler Taveira de Oliveira
Date:
Subject: magic block in doc functions