On Dec 4, 2009, at 11:05 AM, Tom Lane wrote: >> 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.
So only the child processes would be allowed to load the code? That could make connections even slower if there's a lot of Perl code to be added, though that's also the issue we have today. I guess I could live with that, though I'd rather have such code shared across processes. If it's a badly designed concept, do you have any ideas that are less bad? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
