From: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Alexey Klyukin <alexk(at)waki(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plperl and inline functions -- first draft |
Date: | 2009-11-18 02:11:00 |
Message-ID: | 20091118021100.GB3803@eddie |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 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
Attachment | Content-Type | Size |
---|---|---|
plperl-inline.patch | text/x-diff | 9.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2009-11-18 03:39:59 | magic block in doc functions |
Previous Message | Euler Taveira de Oliveira | 2009-11-18 01:33:59 | Re: Very bad FTS performance with the Polish config |