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

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

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 05:13:06
Message-ID: 34d269d41002022113t13abb1aeic9afefeb0fd164a9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Feb 2, 2010 at 21:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> Yeah the both is gross.  How about:
>> plperl.on_plperl_init
>> plperl.on_plperlu_init
>> plperl.on_init ?
>
> I like the first two.  The problem of selecting a good name for the
> third one is easily solved: don't have it.  What would it be except
> a headache and a likely security problem?

Well its already in.  (FYI its also PGC_SIGHUP)  I included it here
because I wanted to make sure it made sense in context of the other
new plperl GUCs.

I *think* its there so people can:
-"use" the same modules in both
-profile both plperl and plperlu code easily (which is really the same point...)

The main difference between on_init and the other two is the later get
eval()ed in while the former is treated as "perl -e". (Did I get that
right Tim? I did not really look over the first patch).  Im not sure
if there are different consequences for that style...  But I would
venture its done that way so we can profile any perl interpreter
startup stuff we do in plperl.c or the src/pl/plperl/*.pl files.

So there might be a reason for it...

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-03 05:50:35
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Previous:From: Tom LaneDate: 2010-02-03 04:38:33
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

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