Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
>> 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*.

> I like plperl.on_plperl(u)_init better than plperl.on_(un)trusted_init.

I agree. But the question in my mind is the relationship between plperl
and plperlu. I agree with the upthread comment that it would be better
if the init strings for them were entirely separate. ISTM we have got
three categories here:

plperl init done outside Safe (must be SUSET)
plperl init done inside Safe (can be USERSET)
plperlu init (must be SUSET)

and there is no good reason to conflate the first and third, nor to
insist that one must be a subset of the other, which AFAICS is the
effect of the current design. So we need a naming scheme that takes
some account of this. Perhaps

plperl.plperl_init
plperl.plperl_safe_init
plperl.plperlu_init

?

regards, tom lane