Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alex Hunsaker <badalex(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 15:34:04
Message-ID: 10675.1265211244@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Chris CampbellDate: 2010-02-03 15:35:00
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Robert HaasDate: 2010-02-03 15:28:48
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group