Initial refactoring of plperl.c - draft [PATCH]
От | Tim Bunce |
---|---|
Тема | Initial refactoring of plperl.c - draft [PATCH] |
Дата | |
Msg-id | 20091124164330.GB48910@timac.local обсуждение исходный текст |
Ответы |
Re: Initial refactoring of plperl.c - draft [PATCH]
Initial refactoring of plperl.c [PATCH] |
Список | pgsql-hackers |
I've started work on the enhancements to plperl I outlined on pg-general (XXX thread) I have a working implementation of those changes, plus some performance enhancements, that I'm now re-working into a clean set of tested and polished patches. This patch is a first step that doesn't add any extra functionality. It refactors the internals to make adding the extra functionality easier (and more clearly visible). Changes in this patch: - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Adds a test for the effect of the utf8fix function. I'd appreciate any feedback on the patch. The next step I plan is to move the large multi-line string literal macros (PERLBOOT, SAFE_OK etc) into external perl code files. That'll make refactoring, extending and maintaining that perl code far simpler. A $pkglib_path/perl directory seems an appropriate place for this code. Assuming that's okay, how should I go about creating that directory and putting files there during build/installation? I could implement that and include it as an update to this patch, or as a new patch on top. Which would be preferable? Tim.
Вложения
В списке pgsql-hackers по дате отправления: