Robert Haas <robertmh...@gmail.com> writes: > On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker <bada...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers