Re: First feature patch for plperl - draft [PATCH]

On Fri, Dec 4, 2009 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> So, do we look for another way to provide the functionality besides
>> having a GUC, or is the functionality itself bad?
>
> I don't think we want random Perl code running inside the postmaster,
> no matter what the API to cause it is.  I might hold my nose for "on
> load" code if it can only run in backends, though I still say that
> it's a badly designed concept because of the uncertainty about who
> will run what when.  Shlib load time is not an event that ought to be
> user-visible.

I agree that the uncertainty is not a wonderful thing, but e.g. Apache
has the same problem with mod_perl, and you just deal with it. I
choose to deal with it by doing "apachectl graceful" every time I
change the source code; or you can install Perl modules that check
whether the mod-times on the other modules you've loaded have changed
and reload them if so. In practice, being able to pre-load the Perl
libraries you're going to want to execute is absolutely essential if
you don't want performance to be in the toilet. My code base is so
large now that it takes 3 or 4 seconds for Apache to pull it all in on
my crappy dev box, but it's blazingly fast once it's up and running.
Having that be something that happens on the production server only
once a week or once a month when I roll out a new release rather than
any more frequently is really important.

...Robert