Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Дата | |
Msg-id | 34d269d41002030651g404dfbabxed031776e7559552@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Add on_trusted_init and on_untrusted_init to plperl
UPDATED [PATCH]
|
Список | pgsql-hackers |
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan <andrew@dunslane.net> wrote: > > > Alex Hunsaker wrote: >>>>> >>>>> Well its already in. >>>>> >>>> >>>> Well *that's* easily fixed. I think it's a bad idea, because it's >>>> unclear what you should put there and what the security implications >>>> are. >>> >>> I can't speak for its virtue, maybe Tim, Andrew? > Regarding the naming of the params, I'm not keen to have more than one > custom_variable_class for plperl. Within that, maybe we can bikeshed the > names a bit. I don't have terribly strong feelings. Hey! I don't think were quite to that nasty B word yet :) I would argue that treating plperl and plperlu as the same language just because it shares the same code is a mistake. But I hate the idea of two custom_variable_classes for plperl(u) as well. Which is why I quickly switched to plperl.on_plperl(u)_init. Any thoughts on those? Again maybe people think the original names are fine... *shrug*.
В списке pgsql-hackers по дате отправления: