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

From Alexey Klyukin
Subject Re: plperl and inline functions -- first draft
Date
Msg-id E072FC9F-B9FB-4EB7-94CC-9B8EE8ED98D7@commandprompt.com
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 Nov 18, 2009, at 5:46 AM, Andrew Dunstan wrote:

>
>
> Joshua Tolley wrote:
>> +     plperl_call_data *save_call_data = current_call_data;
>> +     bool        oldcontext = trusted_context;
>> + +     if (SPI_connect() != SPI_OK_CONNECT)
>> +         elog(ERROR, "could not connect to SPI manager");
>>
> ...
>> +     current_call_data = (plperl_call_data *) palloc0(sizeof(plperl_call_data));
>> +     current_call_data->fcinfo = &fake_fcinfo;
>> +     current_call_data->prodesc = &desc;
>>
>
> I don't think this is done in the right order. If it is then this comment in plperl_func_handler is wrong (as well as
containinga typo): 
>
>   /*
>    * Create the call_data beforing connecting to SPI, so that it is not
>    * allocated in the SPI memory context
>    */
>

Yes, current_call_data can't be allocate in the SPI memory context, since it's used to extract the result after
SPI_finishis called, although it doesn't lead to problems here since no result is returned. Anyway, I'd move
SPI_connectafter the current_call_data initialization. 

I also noticed that no error context is set in the inline handler, not sure whether it really useful except for the
sakeof consistency, but in case it is - here is the patch: 


--
Alexey Klyukin                    http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc


Attachment

pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Rejecting weak passwords
Next
From: Pavel Stehule
Date:
Subject: Re: RFC for adding typmods to functions