Re: Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH] |
Дата | |
Msg-id | 34d269d41002051308t5539e489m25c3d7e954658697@mail.gmail.com обсуждение исходный текст |
Ответ на | Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH] (Tim Bunce <Tim.Bunce@pobox.com>) |
Список | pgsql-hackers |
On Fri, Feb 5, 2010 at 06:40, Tim Bunce <Tim.Bunce@pobox.com> wrote: > This is the third update to the fourth of the patches to be split out > from the former 'plperl feature patch 1'. > > Changes in this patch: > > - Added plperl.on_plperl_init and plperl.on_plperlu_init GUCs > Both are PGC_SUSET > SPI functions are not available when the code is run. > Errors are detected and reported as ereport(ERROR, ...) > Corresponding documentation and tests for both. *sniffle* OK I think I agree with everyone else on setting this as PGC_SUSET until we can either prove it can be USERSET or we can fix it so we can check permissions on SET properly. It seems if you really wanted a user to be able to set it you should be able to define a SECURITY DEFINER function that sets it to a string you pass in or something. Obviously not part of core postgres... > - Renamed plperl.on_perl_init to plperl.on_init *shrug* OK (I think there was still some flack on this var, but I think its ok-- we can discuss that in a separate thread if people still disagree :) ) > - Improved state management of select_perl_context() > An error during interpreter initialization will leave > the state (interp_state etc) unchanged. > > - The utf8fix code has been greatly simplified. > > - More code comments re PGC_SUSET and no access to SPI functions. I like the doc changes and think the new comment about %_SHARED being unsafe is good. All looks good to me. Ill mark it as "Ready for Committer"
В списке pgsql-hackers по дате отправления: