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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
