Re: pl/python refactoring - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: pl/python refactoring
Date
Msg-id 4D3B55F0.9030803@wulczer.org
Whole thread Raw
In response to Re: pl/python refactoring  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 22/01/11 21:53, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
> 
>> Refactor PLy_spi_prepare to save two levels of indentation.
>>
>> Instead of checking if the arglist is NULL and then if its length is
>> 0, do it in one step, and outside of the try/catch block.
> 
> Why is it a good idea to do the PLy_malloc calls outside of the
> try/catch block?  Also, why call them when nargs is 0?

I think it's better to call them outside of the try/catch, because if
palloc failed, we'de be better off just interrupting the function
execution and raising an error than catching the longjmp and turning it
into a Python exception, which will probably make Python fail with a
MemoryError really soon. And I've even seen Python segfaulting when it
ran out of memory instead of raising a MemoryError exception.

As for the nargs == 0 case, you're right, it should read

plan->types = nargs ? PLy_malloc(sizeof(Oid) * nargs) : NULL;

especially since PLy_plan_dealloc does

if (ob->types)  PLy_free(ob->types)

Cheers,
Jan


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: FOR KEY LOCK foreign keys
Next
From: Jan Urbański
Date:
Subject: Re: plpython versus gcc 4.5.x