Re: plperl and inline functions -- first draft

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alexey Klyukin <alexk(at)waki(dot)ru>
Cc: Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plperl and inline functions -- first draft
Date: 2009-11-17 23:05:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

> 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);




In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Wojciech Knapik 2009-11-17 23:27:06 Very bad FTS performance with the Polish config
Previous Message Tom Lane 2009-11-17 23:01:52 Re: RFC for adding typmods to functions