On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
> On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce <tim.bu...@pobox.com> wrote:
> > I didn't get any significant feedback from the earlier draft so here's
> > the finished 'feature patch 1' for plperl.  (This builds on my earlier
> > plperl refactoring patch, and the follow-on ppport.h patch.)
> >
> > Significant changes from the first draft:
> > - New GUC plperl.on_perl_init='...perl...' for admin use.
> > - New GUC plperl.on_trusted_init='...perl...' for plperl user use.
> > - New GUC plperl.on_untrusted_init='...perl...' for plperlu user use.
> 
> I kind of thought Tom said these were a bad idea, and I think I kind
> of agree.

Tom had some concerns which I believe I've addressed.
I'd be happy to hear from Tom if he has any remaining concerns.

> We're not going to support multi-line values for GUCs
> AFAIK, so this is going to be pretty kludgy.

I'm not sure what you mean by "this". Typical use-cases would be:
        plperl.on_perl_init='use MyStuff;'
        plperl.on_trusted_init='$some_global=42';

> What about making the value a comma-separated list of module names to
> use, or something?

That would force people who just want to set some global variable
to write a module. That seems overly painful for no significant gain.
The fact that multi-line values for GUCs aren't supported will naturally
enourage anyone wanting to execute many statements to write a module for
them. That sems like a perfectly reasonable balance.

> > [...]
> 
> The rest of this all seems pretty nice, though I haven't read the patch yet.

Thanks Robert. I look forward to your feedback if you do get a chance to read 
it.

Tim.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to